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ABSTRACT 


This  study  addresses  the  role  of  the  US  Army  Training  and  Doctrine  Command, 
as  the  Army's  principal  Combat  Developer,  in  planning  for  and  providing 
post-deployment  software  support  to  battlefield  automated  systems.  It  is  a 
three-phase  effort  directed  toward  defining  a  viable,  feasible,  and  cost 
effective  functional  and  management  structure  for  the  Combat  Developer  to 
provide  post-deployment  software  support  for  battlefield  automated  systems, 
within  the  framework  of  Army  doctrine  and  policy,  the  Post-Deployment  Soft¬ 
ware  Support  Concept  Plan  for  Battlefield  Automated  Systems,  and  related 
functional  requirements  of  the  Combat  Developer. 

This  report  documents  the  results  of  Phase  I.  The  Phase  I  effort  was  con¬ 
ducted  to  identify  and  describe  the  macro-management  level  and  Battlefield 
Functional  Area  level  post-deployment  software  support  structure  and  processes, 
relating  these  processes  to  other  Combat  Developer  functions,  and  identifying 
the  Combat  Developer's  post-deployment  software  support  requirements.  The 
collection  of  data  to  support  accomplishment  of  Phase  I  involved  an 
extensive  literature  research  effort;  visits  to  organizations  involved  with 
various  aspects  of  post-deployment  software  support  at  Headquarters, 

Department  of  the  Army,  the  US  Army  Training  and  Doctrine  Command  and  its 
Centers  and  Schools,  and  five  other  Army  commands;  and  administering  a 
questionnaire  designed  to  obtain  detailed  information  on  each  battlefield 
automated  system  being  addressed.  These  data  were  then  analyzed  to  develop 
a  description  of  the  current  Army  post-deployment  software  support  system 
and  processes  at  the  macro-management  and  battlefield  functional  area  levels. 
This  description  addresses  organizational  responsibilities,  regulatory  and 
other  directive  authorities,  and  the  battlefield  automated  systems  that 
must  be  supported. 


During  Phase  II  of  the  study,  three  alternative  functional  and  management 
structures  are  to  be  defined,  which  would  enable  the  US  Army  Training  and 
Doctrine  Command  to  accomplish  those  post- deployment  software  support 
functions  that  are  the  responsibility  of  the  Combat  Developer.  Following 
selection  of  one  of  these  three  alternatives.  Phase  III  of  this  study  will 
proceed  with  the  objective  of  developing  an  implementation  plan  that  would 
provide  for  transitioning  from  the  present  to  implementation  of  the  selected 
alternative. 


XV 


SUMMARY 

1.  INTRODUCTION.  The  requirement  to  provide  Post-Deployment  Software 
Support  (PDSS)  to  the  growing  number  of  Battlefield  Automated  Systems  (BAS) 
projected  to  enter  the  Army  inventory  during  the  next  several  years  is  of 
increasing  concern  within  the  Army.  The  User,  Materiel  Developer,  and 
Combat  Developer  all  have  essential  roles  in  the  total  effort  to  provide 
effective  PDSS  for  BAS.  The  US  Army  Training  and  Doctrine  Command  (TRADOC), 
as  the  Army's  principal  Combat  Developer,  is  responsible  for  the  overall 
Army  Battlefield  System.  This  responsibility  includes  determining  what 
capability  is  required  and  when  it  is  required.  The  magnitude  and  complexity 
of  fulfilling  this  responsibility,  especially  with  respect  to  automated 
systems,  necessitates  that  the  Combat  Developer  maintain  close  coordination 
and  interface  with  the  User  and  Materiel  Developer  to  ensure  that  maximum  use 
is  made  of  Developer  capabilities  and  that  User  requirements  are  realized  to 
the  maximum  extent  possible.  Within  this  general  concept,  the  specific  role 
of  the  Combat  Developer  in  the  evolving  Army  system  for  providing  PDSS  to  BAS 
must  be  defined.  The  functional  and  management  structure  and  resource  re¬ 
quirements  necessary  to  enable  the  Combat  Developer  to  carry  out  this  role 
must  be  identified  and  addressed  in  an  implementation  plan  that  will  provide 
for  transitioning  from  the  current  situation  to  achievement  of  the  required 
capability  to  provide  PDSS.  This  study  is  the  first  step  in  moving  toward 
the  definition  and  acquisition  of  this  capability. 

2.  PURPOSE.  The  purpose  of  this  study,  is  to  define,  in  detail,  a  viable, 
feasible  and  cost  effective  functional  and  management  structure  for  the 
Combat  Developer  to  provide  PDSS  for  BAS,  within  the  framework  of  Army 
doctrine  and  policy,  the  DARCOM/Army  PDSS  Study/Management  Plan  and  the 
related  functional  requirements  of  the  Combat  Developer. 

3.  DISCUSSION. 

a.  Background. 

(1)  While  it  has  always  been  accepted  that  the  development  of 
software  systems  is  a  difficult  and  challenging  task,  it  is  now  recognized 
that  the  maintenance  of  these  software  systems  after  deployment  is  just  as 
challenging,  if  not  more  so,  than  the  initial  development.  Furthermore,  the 
magnitude  of  the  effort  required  to  provide  effective  PDSS  to  BAS  is  increas¬ 
ing  rapidly  as  more  and  more  systems  are  fielded. 

(2)  Recognizing  the  need  for  better  planning  and  an  improved 
capability  for  providing  PDSS  to  BAS,  the  US  Army  Materiel  Development  and 
Readiness  Command  (DARCOM)  initiated  a  study  in  May  1978,  directed  toward 
developing  a  concept  for  a  systematic  approach  to  the  planning  for  and  pro¬ 
vision  of  PDSS  for  BAS  on  an  Army-wide  basis.  Within  DARCOM,  the  Communica¬ 
tions  Research  and  Development  Command  (CORADCOM)  was  tasked  with  the  primary 
responsibility  for  the  study.  A  task  force  of  representatives  from  Army  staff 
agencies,  Army  commands  (including  TRADOC  and  its  subordinate  commands),  and 


m 
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Army  project  managers  was  formed  to  work  with  CORADCOM  in  this  effort.  The 
results  of  this  study  are  documented  as  a  Department  of  the  Army  report  en¬ 
titled,  Post-Deployment  Software  Support  Plan  for  Battlefield  Automated 
Systems,  dated  May  1980.  Both  DARCOM  and  TRADOC  have  concurred  in  this  re¬ 
port  which  is  being  forwarded  to  Headquarters,  Department  of  the  Army  for 
staffing. 

(3)  The  PDSS  Concept  Plan  addresses  the  need  for  and  problems 
associated  with  PDSS  for  BAS.  It  outlines  the  general  roles  and  missions  of 
both  the  Combat  Developer  and  Materiel  Developer  in  planning  for  and  providing 
PDSS.  It  also  contains  a  recommended  PDSS  management  plan  and  a  conceptual 
system  structure  and  model  for  providing  PDSS. 

(4)  Within  this  basic  conceptual  framework,  the  Combat  Developer's 
role  and  resource  requirements  must  be  further  defined  to  provide  a  basis 
for  implementation  planning.  This  current  study.  An  Assessment  of  the 
Combat  Developer's  Role  in  Post-Deployment  Software  Support,  has  been 
initiated  by  TRADOC  as  the  initial  step  in  this  effort. 

(5)  This  study  focuses  upon  TRADOC' s  role,  as  the  Army's  principal 
Combat  Developer,  in  planning  for  and  providing  PDSS  for  BAS.  To  further 
clarify  the  scope  of  this  effort,  Post-Deployment  Software  Support  is 
defined  as  that  part  of  overall  system  support  necessary  to  sustain,  modify, 
and  improve  a  deployed  system's  computer  software  as  defined  by  the  User  or 
his  representative.  It  includes  evaluation,  development,  and  timely 
implementation  of  system  and  software  modifications  to  accommodate  trouble 
reports;  User  proposed  changes;  and  changes  to  satisfy  new  or  revised 
doctrinal,  tactical,  procedural  or  interoperability  requirements. 

b.  Methodology.  This  study  is  to  be  completed  through  the  accomplish¬ 
ment  of  eight  tasks  divided  into  three  phases  over  an  eight  month  period, 
which  began  on  30  June  1980.  This  First  Interim  Technical  Report  documents 
the  results  of  Phase  I. 

(1)  Phase  I  was  directed  toward  analyzing  the  current  Army  PDSS 
system  and  associated  processes  at  both  the  macro-management  and  the  Battle¬ 
field  Functional  Area  (BFA)  levels,  and  identifying  the  Combat  Developer's 
PDSS  requirements  at  the  BFA  level.  The  BFA  concept  provides  a  systematic 
way  of  describing  the  actions  that  systems  perform  and  the  functional  area 
in  which  they  operate  in  accomplishing  the  commander's  mission  of  viewing 
the  battlefield,  planning  operations,  allocating  resources,  fighting  the 
battle,  and  sustaining  the  force.  The  methodology  employed  involved  data 
collection,  analysis,  and  documentation  efforts.  Data  collection  was 
accomplished  through  (a)  an  extensive  literature  review  and  research  effort; 
(b)  visits  to  18  Army  organizations  including  elements  of  the  Army  Staff, 
Headquarters,  US  Army  Training  and  Doctrine  Command  (TRADOC),  five  other 
major  commands  and  field  operating  agencies,  and  eight  TRADOC  centers  and 


schools;  and  (c)  developing  and  administering  a  questionnaire  designed  to 
obtain  detailed  information  on  the  BAS  being  addressed.  These  data  were 
then  collated  and  analyses  of  the  macro-  and  BFA-level  PDSS  processes  were 
developed.  A  description  was  also  developed  of  TRADOC's  PDSS  requirements 
as  perceived  by  elements  of  TRADOC  Centers  responsible  for  performing  the 
Combat  Developer's  functions  in  providing  PDSS  to  BAS.  These  analyses  and 
the  description  of  PDSS  requirements  are  presented  in  the  body  of  this 
First  Interim  Technical  Report. 

(2)  Phase  II  of  the  study  will  be  directed  toward  the  definition 
of  three  alternative  TRADOC  PDSS  models  or  systems  that,  when  implemented, 
would  provide  TRADOC  a  capability  to  accomplish  its  PDSS  role.  These  alter¬ 
natives  are  to  be  documented  in  the  Second  Interim  Technical  Report  due  on 
16  December  1980. 

(3)  Following  TRADOC  selection  of  a  preferred  model  from  among 
the  alternatives  defined  during  Phase  II,  the  Phase  III  Study  effort  will 
proceed.  During  Phase  III,  an  implementation  plan  is  to  be  developed  which 
will  provide  for  transition  from  the  present  to  implementation  of  the 
selected  alternative  model.  This  implementation  plan  is  to  be  documented 
in  the  Third  Interim  Technical  Report  due  on  1  February  1981. 

(4)  A  Final  Report  is  to  be  completed  during  the  last  month  of 
the  project  and  submitted  on  28  February  1981. 

c.  Analysis.  The  Phase  I  research  and  analysis  addressed  three 
component  areas  of  both  the  macro-  and  BFA-level  PDSS  structure  and  processes. 
These  areas  are  the  organizational  elements  involved,  the  applicable 
regulatory  policies  and  directives,  and  the  BAS  for  which  PDSS  must  be 
provided. 

(1)  Significant  elements  of  this  analysis  at  the  macro-management 
level  revealed: 

(a)  Regulatory  policy  governing  the  acquisition  and  life  cycle 
management  of  automated  systems  in  the  Army  is  divided  between  two  separate 
sets  of  regulations— the  AR  18-series  and  the  AR  1000-1/AR  70-series.  Each 
set  of  regulations  is  published  under  the  proponency  of  a  different  element  of 
Headquarters,  Department  of  the  Army.  This  is  a  source  of  irritation, 
differences  in  interpretation,  and  potential  problems  in  establishing  an 
effective  system  for  planning  and  providing  PDSS  for  BAS.  Efforts  are  being 
made,  in  connection  with  recent  or  pending  changes  to  these  regulations,  to 
minimize  differences  and  harmonize,  to  the  extent  possible,  the  provisions  of 
each  set  of  regulations.  A  memorandum  from  the  Assistant  Secretary  of  Defense 
(Research,  Development,  and  Acquisition),  1  July  1980,  subject:  "Standardiza¬ 
tion  of  Embedded  Computer  Resources",  and  a  letter  from  the  Deputy  Commander, 
TRADOC,  file:  ATDC,  30  July  1980,  same  subject,  bear  directly  on  this  problem 
and  contribute  to  its  resolution.  However,  some  differences  may  remain 
because  of  the  need  to  comply  with  special  requirements  imposed  by  applicable 
Public  Law  and  0MB  policy. 


(b)  Post-deployment  support  of  automated  systems  in  general 
and  post-deployment  software  support  in  particular  are  not  adequately 
addressed  in  Army  regulatory  documents.  This  situation  has  been  improved  to 
some  extent  with  the  recent  (August  1980)  issuance  of  revised  AR  18-1  and 
should  be  further  improved  as  a  result  of  revisions  being  made  to  ARs  70-1 
and  1000-1  which  contain  basic  policies  for  system  acquisition  and  life  cycle 
management  within  the  Army.  Major  command-level  implementation  of  these 
revised  regulations  will  be  required  following  their  publication. 

(c)  Despite  the  above  problem  areas,  the  current  assignment 
of  missions  and  functions  to  elements  of  the  Army  Staff  and  major  commands 
in  the  AR  10-series  provides  an  adequate  framework  for  the  development  of  a 
system  for  providing  POSS  for  BAS. 

(2)  Analysis  at  the  TRADOC  and  BFA  levels  indicates  that  TRADOC, 
as  the  Army's  principal  Combat  Developer,  has  a  major  role  in  the  overall 
PDSS  effort.  This  critical  and  increasing  role  is  largely  due  to: 

•  The  trend  toward  embedding  more  doctrine,  tactics,  and  functional 
procedures  in  BAS  software  which  necessitates  more  direct  CD 
participation  in  analysis  and  decisions  pertaining  to  system  changes 
that  could  affect  any  of  these  areas, 

•  The  growing  number  of  BAS  being  fielded  which  makes  definition  and 
maintenance  of  functional  interoperability  requirements  more 
complex,  and 

•  The  continually  evolving  nature  of  some  BAS  which  is  now  an 
accepted  system  development  approach  per  DODI  5000.2,  but  which 
has  major  implications  for  System  and  Combat  Developers,  Users, 
and  all  system  support  activities. 

TRADOC’s  specific  PDSS  responsibilities  derive  primarily  from  the  basic  mission 
set  forth  in  AR  10-41,  Organization  and  Functions,  US  Army  Training  and 
Doctrine  Command.  They  fall  into  all  the  principal  task  areas  essential  for 
effective  PDSS.  These  task  areas  include: 

•  Management 

•  Analysis 

•  System  Modification 

•  System  Testing 

t  Field  Support 

(3)  All  TRADOC  Centers  and  Schools  that  are  designated  as  the 
proponent  for  one  or  more  BAS  have  responsibilities  in  each  of  the  functional 
task  areas  listed  above.  However,  in  most  cases,  additional  resources  are 
needed  to  effectively  perform  these  functions.  These  resource  needs  will 
become  more  critical  as  additional  and  more  advanced  BAS  enter  the  inventory 
and  associated  support  requirements  increase  and  become  more  complex.  Tentative 
resource  requirements  have  been  identified  by  combat  developments  personnel 
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at  most  TRADOC  doctrinal  centers.  These  estimates  were  provided  to  the 
Study  Team  during  Phase  I.  Further  analysis  is  necessary  during  Phase  II 
of  this  study  to  refine  these  requirements  and  develop  conceptual  systems 
for  the  most  effective  organization  and  application  of  these  resources  to 
satisfy  Combat  Developer  PDSS  responsibilities  in  each  BFA. 
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CHAPTER  1 
INTRODUCTION 


1-1.  STATEMENT  OF  THE  PROBLEM. 

a.  Need  for  PDSS.  The  requirement  to  provide  Post-Deployment 
Software  Support  (PDSS)  to  the  growing  number  of  Battlefield  Automated 
Systems  (BAS)  projected  to  enter  the  Army  inventory  during  the  next 
several  years  is  one  of  increasing  concern  within  the  Army.  If  the 
Army's  BAS  are  to  function  as  intended,  and  as  they  must  if  the  full 
effectiveness  of  other  modern  battlefield  systems  that  are  supported  by 
or  dependent  upon  BAS  is  to  be  realized,  a  means  must  be  developed  and 
implemented  for  providing  timely  and  effective  post-deployment  software 
support. 

b.  General  Roles  in  Providing  PDSS.  The  User,  Materiel  Developer, 
and  Combat  Developer  all  have  essential  roles  in  the  total  effort  to  provide 
effective  PDSS  for  BAS.  The  US  Army  Training  and  Doctrine  Command  (TRADOC), 
as  the  Army's  principal  Combat  Developer  and  the  "battlefield  architect",  is 
responsible  for  the  overall  Army  Battlefield  System  (ABS).  This  respon¬ 
sibility  includes  determining  what  capability  is  required  and  when  it  is 
required.  The  magnitude  and  complexity  of  fulfilling  this  responsibility, 
especially  with  respect  to  automated  systems,  necessitates  that  the  Combat 
Developer  maintain  close  coordination  and  interface  with  the  User  and 
Materiel  Developer  to  ensure  that  maximum  use  is  made  of  Materiel  Developer 
capabilities  and  that  User  requirements  are  realized  to  the  extent  possible. 
This  Combat  Developer  responsibility  applies  to  both  the  initial  system 
development  and  to  any  subsequent  post-deployment  changes  to  a  system. 

c.  Need  for  this  Study.  Within  this  general  concept,  the  specific 
role  of  the  Combat  Developer  in  the  evolving  Army  system  for  providing  PDSS 
to  BAS  must  be  defined.  The  functional  and  management  structure  and  the 
resource  requirements  necessary  to  enable  the  Combat  Developer  to  carry  out 
this  role  must  be  identified  and  addressed  in  an  implementation  plan  that 
will  provide  for  transitioning  from  the  current  situation  to  achievement 

of  the  required  capability  to  provide  PDSS.  This  study  is  the  first  step  in 
moving  toward  the  acquisition  of  this  required  capability. 

1-2.  BACKGROUND. 

a.  Growing  Importance  of  PDSS.  Post-deployment  software  support,  or 
maintenance,  of  BAS  is  of  major  importance  to  all  Users  of  these  systems  and 
to  commanders  who  must  depend  upon  them  for  accomplishment  of  their  missions. 
While  it  has  always  been  accepted  that  the  development  of  software  systems 
is  a  difficult  and  challenging  task,  it  is  now  recognized  that  the  main¬ 
tenance  of  these  software  systems  after  deployment  is  just  as  challenging, 
if  not  more  so,  than  the  initial  development.  Furthermore,  the  magnitude 
of  the  effort  required  to  provide  effective  PDSS  to  BAS  is  increasing 
rapidly  as  more  and  more  systems  are  fielded. 
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b.  Previous  PDSS  Study.  Recognizing  the  need  for  better  planning  and 
an  improved  capability  for  providing  PDSS  to  BAS,  the  US  Army  Materiel 
Development  and  Readiness  Command  (DARCOM)  initiated  a  study  in  May  1978, 
directed  toward  developing  a  concept  for  a  systematic  approach  to  the  planning 
for  and  provision  of  PDSS  for  BAS  on  an  Army-wide  basis.  Within  DARCOM,  the 
Communications  Research  and  Development  Command  (CORADCOM)  was  tasked  with 
primary  responsibi 1 ity  for  the  study.  A  task  force  of  representatives  from 
Army  staff  agencies.  Army  commands  (including  TRADOC  and  its  subordinate 
commands),  and  Army  project  managers  was  formed  to  assist  CORADCOM  in  this 
effort.  The  results  of  this  effort  are  documented  as  a  Department  of  the 

Army  report  entitled,  Post-Deployment  Software  Support  Concept  Plan  for 
Battlefield  Automated  Systems,  dated  May  1980.  Both  DARCOM  and  TRADOC  have 
concurred  in  this  report  which  DARCOM  is  forwarding  to  Headquarters ,  Depart¬ 
ment  of  the  Army  for  staffing. 

c.  PDSS  Management  Plan.  The  PDSS  Concept  Plan  cited  above,  includes 
a  comprehensive  addressal  of  the  need  for  and  problems  associated  with  PDSS 
for  BAS.  It  outlines  the  general  roles  and  missions  of  both  the  Combat 
Developer  and  Materiel  Developer  in  planning  for  and  providing  PDSS.  The 
report  also  contains  a  recommended  PDSS  management  plan  and  a  conceptual 
system  structure  and  model  for  providing  PDSS. 

(1)  PDSS  Center  concept.  This  management  plan  recommends  that 
eleven  Materiel /System  Developer-managed  PDSS  Software  Support  Centers  be 
established  to  perform  post-deployment  software  support  for  designated  BAS. 

The  plan  provides  for  locating  five  of  these  PDSS  Centers  at  TRADOC  doctrinal 
centers.  Five  others  are  to  be  located  at  DARCOM  development  commands  and 
one  at  the  Computer  Systems  Command  (CSC).  Of  the  five  PDSS  Centers  at 
TRADOC  doctrinal  centers,  four  would  be  managed  by  DARCOM  development  commands 
(by  CORADCOM  at  Fort  Sill,  by  MICOM  at  Fort  Bliss,  by  ERADCOM  at  Fort 
Hauchuca,  and  by  CORADCOM  at  Fort  Leavenworth).  The  fifth  one  would  be 
managed  by  CSC  at  Fort  lee.  Figure  1-1  identifies  all  eleven  PDSS  Centers, 
their  location,  and  the  materiel /system  development  command  that  will  be 
managing  each  Center.  Appendix  C  identifies  which  BAS  are  to  be  supported 

at  each  PDSS  Center. 

(2)  Concept  for  Combat  Developer  interface.  The  management  plan 
cited  above  also  recognizes  the  need  for  Combat  Developer  interaction  with 
these  PDSS  Centers.  It  provides  for  this  interface  through  a  concept  pro¬ 
posing  the  designation  of  Combat  Development  System  Managers  (CDSM)  and  the 
establishment  of  Combat  Development  Support  Facilities  (CDSF)  as  determined 
by  TRADOC  to  be  needed. 

(a)  CDSM  concept.  Under  this  concept,  the  CDSM  would  be  the 
system/software  Combat  Developer  (CD)  and  the  principal  Field  User’s  repre¬ 
sentative  for  a  designated  system  or  group  of  systems  within  a  Battlefield 
Functional  Area  (8FA).  He  would  be  responsible  for  managing  and  coordinating 
all  software  related  actions  inherent  in  the  CD  mission. 
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PDSS  CENTERS 

CENTER 

LOCATION 

MANAGED  BY 

1 

PICATINNY  ARSENAL 

ARRADCOM 

2 

FORT  MONMOUTH 

CORADCOM 

3 

FORT  LEAVENWORTH 

CORADCOM 

4 

FORT  BELVOIR 

CSC 

5 

FORT  LEE 

CSC 

6 

FORT  BLISS 

MICOM 

7 

FORT  SILL 

CORADCOM 

8 

FORT  HUACHUCA 

ERADCOM 

9 

FORT  MONMOUTH  ' 

ERADCOM 

10 

REDSTONE  ARSENAL 

MICOM 

11 

FORT  MONMOUTH 

AVRADCOM 

Figure  1-1.  Proposed  PDSS  Centers 
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(b)  COSF  concept.  CDSF  would  be  a  TRADOC  facility  with 
responsibility  for  performing  the  CD  PDSS  role  for  BAS  in  one  or  more  BFA. 

The  concept  envisions  that  the  CDSF  might  be  collocated,  in  whole  or  in  part, 
with  an  MD  PDSS  Center  or  could  be  located  separately.  Also  as  envisioned 
in  the  PDSS  Concept  Plan,  a  CDSF  would  provide  both  the  system/software 
analytical  capability  and  the  technical  personnel  necessary  to  perform  CD 
PDSS  functions. 

d.  Development  and  Implementation  of  Concept.  While  the  PDSS  Concept 
Plan  for  BAS  provides  a  basic  conceptual  framework  for  PDSS,  the  Combat 
Developer's  role  and  resource  requirements  must  be  further  defined  to  provide 
a  basis  for  implementation  planning.  This  current  study,  An  Assessment  of 
the  Combat  Developer's  Role  in  Post-Deployment  Software  Support,  has  been 
initiated  by  TRADOC  as  the  initial  step  in  planning  for  implementation  of 
the  PDSS  Concept  Plan  resulting  from  the  DARCOM-initiated  study  discussed 
above. 


1-3.  OBJECTIVE. 

a.  Overall  Study.  The  objective  of  this  study  is  to  define,  in 
detail,  a  viable,  feasible,  and  cost  effective  functional  and  management 
structure  through  which  the  Combat  Developer  can  fulfill  his  role  in 
providing  Post-Deployment  Software  Support  for  Battlefield  Automated  Systems 
within  the  framework  of  Army  doctrine  and  policy,  the  DARCOM/Army  PDSS 
Concept  Plan  for  Battlefield  Automated  Systems  and  the  related  functional 
requirements  of  the  Combat  Developer. 

b.  Phase  I.  The  objective  of  Phase  I,  which  is  documented  in  this 
report,  is  to  gain  a  better  understanding  of  PDSS  requirements  by  identifying 
and  describing  the  macro-management  level  and  Battlefield  Functional  Area 
(BFA)  level  PDSS  processes  and  associating  these  with  the  other  CD  functions, 
all  within  the  context  of  the  DARCOM/Army  PDSS  Study/Management  Plan. 

1-4.  SCOPE. 

a.  General .  This  study  focuses  upon  TRADOC 's  role,  as  the  Army's 
principal  Combat  Developer,  in  planning  for  and  providing  PDSS  for  BAS.  The 
BAS  to  be  addressed  are  listed  in  Appendix  C.  Primary  emphasis  is  placed 

on  Category  1  and  2  and  CSC-developed  BAS,  as  categorized  during  the 
previous  DARCOM-initiated  PDSS  study. 

b.  Definitions .  To  further  clarify  this  scope,  Post-Deployment 
Software  Support  is  defined  as  that  part  of  overall  system  support  necessary 
to  sustain,  modify,  and  improve  a  deployed  system's  computer  software  as 
defined  by  the  User  or  his  representative.  It  includes  evaluation,  development, 
and  timely  implementation  of  system  and  software  modifications  to  accommodate 
trouble  reports;  User  proposed  changes;  and  changes  to  satisfy  new  or  revised 
doctrinal,  tactical,  procedural  or  interoperability  requirements.  Battlefield 
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Automated  System  is  defined  as  a  system  employing  computer  resources  that 
operates  or  has  components  that  operate  within  the  boundaries  of  the  battle¬ 
field,  regardless  of  the  function,  mission,  or  battle  involvement.  The 
systems  may  be  an  offensive,  defensive,  or  direct/indirect  support  system. 
Examples  of  such  systems  are  weapons,  communications,  command  and  control, 
intelligence,  avionics,  missiles,  combat  support  and  combat  service  support 
systems. 


c.  Relationship  of  PDSS  and  Life  Cycle  Management.  While  the  study 
focuses  on  PDSS  as  defined  above,  PDSS  must  be  addressed  as  an  integral  part 
of  system  life  cycle  management.  Figure  1-2  illustrates  the  relationship  of 
PDSS  to  the  system  life  cycle.  As  indicated,  planning  for  PDSS  must  begin 
early  during  system  development  (prior  to  Milestone  II  per  draft  AR  70-1) 
and  continue  throughout  the  system  life  cycle.  Consequently,  in  researching 
and  analyzing  PDSS  responsibilities  and  requirements,  it  has  been  necessary 
to  address  certain  other  related  processes  and  interactions  in  systems 
development  and  life  cycle  management  to  include  requirements  definition  and 
analysis,  training  development,  and  a  broad  range  of  User-Combat  Developer- 
Materiel  Developer  interactions.  It  has  also  been  necessary  to  consider  the 
relationship  between  PDSS  and  the  other  basic  functions  of  the  Combat 
Developer  which  include: 

•  Research  and  Analysis 

•  Development  of  System  Software  Requirements 

t  Training  Development 

•  Guidance  to  the  Field 

«  Support  to  Contingency  Planning  and  Operations 

•  Systems  Testing 

•  Support  of  Wartime/Crisis  Operations 

d.  Classification.  Contract  No.  MDA903-80-C-0479  under  which  this 
study  is  being  conducted  states  that,  "The  highest  classification  involved 
in  the  performance  of  this  contract  is  SECRET."  No  systems,  classified 
SECRET  or  lower,  were  identified  to  the  study  team  during  the  Phase  I 
research  effort.  Therefore,  this  report  is  unclassified.  If  systems 
exist  whose  identity  is  classified  above  the  SECRET  level,  TRADOC  PDSS 
requirements  associated  with  such  systems  must  be  identified  and 
addressed  separately. 

1.5.  METHODOLOGY 

a.  Study  Structure.  Within  the  parameters  of  the  scope  described  in 
Paragraph  1-4,  this  study  is  to  be  completed  through  the  accomplishment  of 
eight  tasks  over  an  eight  month  period  divided  into  three  phases  as  shown  in 
Figure  1-3.  This  figure  also  illustrates  the  relationship  between  the  tasks 
and  phases  of  the  study.  The  study  began  30  June  1980  and  is  scheduled  to 
be  completed  28  February  1981. 


SCHEMATIC  SYSTEM  LIFE  CYCLE 


Figure  1-2.  Illustration  of  the  relationship  of  PDSS 

requirements  and  actions  to  system  life  cycle 
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AN  ASSESSMENT  OF  THE  COMBAT  DEVELOPER'S  ROLE  IN  PDSS 


Figure  1-3.  PDSS  study  overview 
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b.  Phase  I.  Phase  I  began  upon  contract  award.  It  consisted  of  Tasks 
1  through  4. 

(1)  Task  1.  The  Work  Plan  prepared  during  Task  1  was  delivered 
to  the  Contracting  Officers  Technical  Representative  on  17  July  1980.  This 
plan  was  then  presented  to  and  approved  by  the  Study  Advisory  Group  (SAG)  at 
its  initial  meeting  on  14  August  1980. 

(2)  Tasks  2,  3  and  4.  Tasks  2,  3,  and  4  of  Phase  I  began  in  early 
July.  This  First  Interim  Technical  Report  documents  the  results  of  the 
effort  devoted  to  these  three  tasks.  Their  accomplishment  involved  data 
collection,  analysis  and  documentation  efforts.  The  data  collection  was 
accomplished  through  the  following  steps: 

(a)  An  extensive  literature  review  and  research  effort  in¬ 
volving  the  reference  material  listed  in  Appendix  A,  plus  numerous  other 
documents  that,  after  review,  were  determined  not  to  be  of  sufficient 
significance,  relevance,  or  currency  to  warrant  their  inclusion  as 
references. 


(b)  Visits  were  made  to  the  organizations  listed  in  Figure 
1-4,  where  interviews,  briefings,  and  informal  discussions  were  held. 

(c)  A  questionnaire  was  administered  during  the  visits  des¬ 
cribed  above.  This  questionnaire  was  designed  to  obtain  more  detailed  in¬ 
formation  on  the  Category  1  and  2  BAS  being  addressed  than  could  conveniently 
be  obtained  in  the  interviews  and  discussions  held  during  the  visits. 

The  data  collected  were  then  analyzed  and  the  results  documented  in  this 
report  which  describes  the  current  macro-  and  BFA-level  PDSS  systems  and 
processes  and  the  functional  and  resource  requirements  necessary  for  TRADOC 
to  fulfill  its  role  in  planning  for  and  providing  PDSS. 

c.  Phase  II.  Phase  II  of  the  study,  consisting  of  Tasks  5,  6,  and  7, 
will  be  directed  toward  the  definition  of  three  alternative  TRADOC  PDSS 
models  or  systems  that,  when  implemented,  would  provide  TRADOC  a  capability 
to  accomplish  its  PDSS  role.  These  alternatives  are  to  be  documented  in  the 
Second  Interim  Report  due  on  16  December  1980. 

d.  Phase  III.  Following  TRADOC  selection  of  a  preferred  model  from 
among  the  alternatives  defined  during  Phase  II,  the  Phase  III  Study  effort 
will  proceed.  During  Phase  III,  an  implementation  plan  is  to  be  developed 
which  would  prqvide  for  transition  from  the  present  to  implementation  of  the 
selected  alternative  model.  This  implementation  plan  is  to  be  documented 

in  the  Third  Interim  Technical  Report  due  on  1  February  1981. 

e.  Final  Report.  A  Final  Report  is  to  be  completed  during  the  last 
month  of  the  project  and  submitted  on  28  February  1981. 
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SCHEDULE  OF  VISITS 

ORGANIZATION 

DATE ( S ) 

TACTICAL  INTEROPERABILITY  SUPPORT  ELEMENT 

24  JULY  1980 

HQ  US  ARMY  TRAINING  AND  DOCTRINE  COMMAND 

4  and  28  AUGUST  1980 

US  ARMY  FIELD  ARTILLERY  CENTER 

4-6  AUGUST  1980 

US  ARMY  TRAINING  SUPPORT  CENTER 

5  AUGUST  1980 

US  ARMY  LOGISTICS  CENTER 

5-6  AUGUST  1980 

US  ARMY  AIR  DEFENSE  CENTER 

6-8  AUGUST  1980 

HQ  DEPARTMENT  OF  THE  ARMY 

7  AUGUST  1980 

HQ  INTELLIGENCE  AND  SECURITY  COMMAND 

8  AUGUST  1980 

HQ  US  ARMY  MATERIEL  DEVELOPMENT  AND  READINESS 
COMMAND 

8  AUGUST  1980 

HQ  COMPUTER  SYSTEMS  COMMAND 

11  AUGUST  1980 

US  ARMY  SIGNAL  CENTER 

20-21  AUGUST  1980 

US  ARMY  INTELLIGENCE  CENTER  AND  SCHOOL 

21-22  AUGUST  1980 

HQ  COMMUNICATIONS  RESEARCH  AND  DEVELOPMENT 
COMMAND 

26-27  AUGUST  1980 

EW  LAB,  ELECTRONICS  RESEARCH  AND  DEVELOPMENT 
COMMAND 

27  AUGUST  1980 

US  ARMY  ENGINEER  CENTER 

29  AUGUST  1980 

ARMY  RESEARCH  INSTITUTE 

29  AUGUST  1980 

US  ARMY  SOLDIER  SUPPORT  CENTER 

2-4  SEPTEMBER  1980 

COMBINED  ARMS  CENTER 

AUGUST/SEPTEMBER 

Figure  1-4.  Organizations  visited  during  Phase  I 
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1-6.  ORGANIZATION  OF  THIS  REPORT.  The  remainder  of  this  First  Interim 
Technical  Report  is  divided  into  three  main  areas;  description  of  the  current 
Army  POSS  System,  the  TRADOC  requirements  for  PDSS  involvement  within  the 
BFAs,  and  problems  and  insight  implications  for  TRADOC. 

a.  Chapter  2.  The  first  area,  discussed  in  Chapter  2,  defines  the 
Army  PDSS  System  in  terms  of  a  systems  concept,  its  macro-  and  micro-level 
organizational  elements,  and  applicable  regulatory  policies  and  procedures, 
and  will  identify  which  BAS  are  addressed  by  the  study. 

b.  Chapter  3.  The  second  area,  discussed  in  Chapter  3,  analyzes  the 
TRADOC  requirements  for  PDSS  involvement  as  perceived  by  representatives 

of  the  BFAs.  This  analysis  discusses  each  BFA  in  terms  of  the  BAS  to  be 
supported,  the  CD  PDSS  functions  to  be  performed,  the  impact  on  the  organ¬ 
izations  performing  these  PDSS  functions,  regulatory  policy  and  procedures, 
and  resource  requirements. 

c.  Chapter  4.  Lastly,  Chapter  4  describes  potential  problem  ar^as 
that  have  been  identified  during  the  course  of  this  first  phase  of  the 
study  and  discusses  insights  and  implications  for  TRADOC. 

1-7.  OBJECTIVES,  APPROACH,  AND  NATURE  OF  THIS  REPORT.  This  report  is  a 
summary  of  material  obtained  from  the  TRADOC  Centers  and  other  sources  during 
the  Phase  I  data  collection  effort.  Review  and  analysis  of  both  this  basic 
source  material  and  the  results  and  conclusions  which  may  be  derived  from 
it  will  continue  into  subsequent  phases  of  this  study  effort.  With  issue  of 
this  report  the  authors  solicit  comments,  additional  information,  and  insights 
that  should  be  considered  in  preparation  of  reports  in  the  later  phases  of 
this  study. 

a.  General .  A  broad  and  responsible  mission  has  been  accepted  by  the 
Study  Team.  All  types  of  information  were  solicited  during  the  visits  and 
interviews  of  the  Phase  I  data  collection  effort.  This  information  covered 
many  subject  areas  and  ranged  from  very  subjective,  personal  judgements  and 
opinions  to  documented  facts  and  figures,  supplemented  with  library 
research.  This  report  is  a  summary  compilation  of  all  of  this  material.  The 
intent  of  this  report  is  to  capture  the  essence  of  the  material,  which  is  too 
voluminous  to  play  back  in  full  detail  in  any  single  document. 

b.  Objectives.  The  primary  objective  in  preparing  this  report  has 
been  to  present  an  accurate  and  objective  picture  of  the  information  obtained 
in  the  research  phase  of  this  effort.  Two  subordinate  objectives  existed: 

(1)  To  provide  feedback,  in  a  depth  of  detail  sufficient  to  permit 
SAG  members  and  other  knowledgeable  reviewers  to  recognize  and  relate  to  the 
issues,  and  thus  provide  a  basis  for  fruitful  discussion. 
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(2)  To  provide  a  baseline  document  and  to  serve  as  a  basis  for 
agreement  regarding  the  issues  which  are  central  to  the  research  and  analysis 
scheduled  for  the  remainder  of  this  study  effort. 

c.  Approach.  To  accomplish  the  necessary  summarization  of  the  material 
collected,  some  judgements  had  to  be  made.  These  pertained  to  the  choice  of 
details  to  be  reported  and  the  level  of  summarization  presented.  Such 
judgements  were  exercised  with  the  above-stated  primary  objective  held 
foremost.  In  some  instances,  inductive  reasoning  and  interpretation  of 
source  material  were  conducted  to  identify  apparent  gaps,  issues,  or  problems. 
In  most  instances,  however,  such  conditions  were  either  identified  to  us  in 
the  interviews  or  were  obvious  from  the  facts  obtained. 

d.  Nature  of  This  Report.  Aside  from  the  relatively  few  judgements 
and  interpretations  mentioned  above,  this  document  is  primarily  a  report  of 
information  collected.  It  serves  as  a  baseline  description  of  the  current 
TRADOC  PDSS  organizational  and  regulatory  structure  and  of  the  future 
requirements  for  PDSS-related  resources  as  perceived  by  TRADOC  personnel 
involved  with  Battlefield  Automated  Systems.  Although  some  issues  that  may 
exist  at  a  specific  TRADOC  Center  or  School  may  not  be  identified,  the 
Study  Team  has  attempted  to  address  all  significant  issues  that  were  raised 
during  discussions  with  BFA  representatives.  Additional  issues,  concerns 
or  comments  that  arise  subsequent  to  delivery  of  this  report,  will  be  con¬ 
sidered  to  the  extent  possible  during  the  next  phases  of  the  study 
effort. 
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CHAPTER  2 

THE  POST-DEPLOYMENT  SOFTWARE  SUPPORT  SYSTEM 

2-1.  GENERAL.  This  chapter  presents  the  results  of  the  research  and  analysis 
conducted  during  the  accomplishment  of  Tasks  2  and  3  which  involved  analyses 
of  Macro-Management  Level  PDSS  Processes  and  BFA-Level  PDSS  Processes, 
respectively.  These  analyses  were  directed  toward  identifying  the  macro- 
and  BFA-level  organizations  that  have  PDSS  responsibilities  and  developing 
descriptions  of  the  processes  through  which  the  planning  for  and  provision 
of  PDSS  to  BAS  are  accomplished.  Research  conducted  during  these  tasks 
revealed  that  PDSS  is  addressed  to  a  very  limited  degree  in  current  Army 
regulatory  documents  and  organizational  charters.  To  the  extent  that  it  is 
addressed,  it  is  discussed  as  an  integral  part  of  the  system  acquisition  and 
life  cycle  management  process.  Thus,  while  the  research  and  analyses 
conducted  under  this  task  were  focused  on  PDSS  functional  responsibilities 
and  associated  processes,  it  was  necessary  in  most  cases  to  examine  the 
broader  functional  areas  of  system  acquisition  and  life  cycle  management  in 
order  to  identify  implicit  PDSS  responsibilities  of  macro-  and  BFA-level 
organizations. 

2-2.  BASIC  COMPONENTS.  Basic  components  of  the  current  post-deployment 
software  support  system  were  identified  and  addressed  in  three  general  areas. 
These  were: 

•  The  macro-  and  BFA-level  organizational  elements  involved, 

•  Applicable  regulatory  policies  and  procedures,  and 

•  The  battlefield  automated  systems  supported. 

Each  of  these  component  areas  is  discussed  below. 

a.  Organizational  Elements.  The  organizational  elements  at  both 
the  macro-  and  BFA-levels  with  principal  responsibilities  related  to  PDSS  are 
identified  and  discussed  briefly  below.  Only  those  organizations  with  major 
responsibilities  are  addressed  since  a  discussion  of  other  organizations  with 
only  minor,  supporting  PDSS  roles  would  contribute  little  to  this  report. 

More  detail  on  the  roles,  responsibilities,  relationships,  and  operating 
procedures  of  the  organizations  identified  is  presented  in  Paragraphs  2-3 
and  2-4. 


(1)  Macro-management  level.  Organizations  with  key  roles  in 
PDSS  at  the  macro-management  level  are  shown  in  Figure  2-1.  Their  respon¬ 
sibilities  related  to  PDSS  are  discussed  below. 

(a)  Army  Secretariat. 

1_.  Assistant  Secretary  of  the  Army  (Research,  Develop¬ 
ment,  and  Acquisition).  The  Assistant  Secretary  of  the  Army  (RDA)  is  the 
Scientific  Advisor  to  the  Secretary  of  the  Army.  Among  other  areas,  he 


FIELD  OPERATING  AGENCIES 

US  ARMY  COMPUTER 
SYSTEMS  COMMAND  (CSC) 

US  ARMY  MILITARY 
PERSONNEL  CENTER 
(MILPERCEN) 

US  ARMY  OPERATIONAL 
TEST  AND  EVALUATION 
AGENCY  (OTEA) 

MAJOR  COMMANDS 


US  ARMY  TRAINING  AND 

■ 

US  ARMY  MATERIEL  ACQUISI- 

DOCTRINE  COMMAND 

■ 

TION  AND  READINESS 

(TRAOOC) 

I 

COMMAND  (DARCOM) 

US  ARMY  INTELLIGENCE 

AND  SECURITY  COMMAND 
(INSCOM) 

US  ARMY  COMMUNICATIONS 
COMMAND  (USACC) 

Figure  2-1.  Organizational  elements  with  key  PDSS 
responsibilities  at  the  macro-manage¬ 
ment  level . 
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is  responsible  for  research,  development,  test,  and  evaluation;  materiel 
acquisition  management;  and  acquisition  policies  and  procedures.  He  has 
cognizance  over  Army  Regulation  1000-1,  Basic  Policies  for  Systems  Acquisition 
by  the  Department  of  the  Army,  and  Army  Regulation  70-1,  Army  Research, 
Development,  and  Acquisition.  He  serves  as  a  member  of  the  Army  Systems 
Acquisition  Review  Council  (ASARC). 

2.  Assistant  Secretary  of  the  Army  (Installations, 
Logistics,  and  Financial  Management).  The  Assistant  Secretary  of  the  Army 
(IL&FM),  among  other  responsibilities,  has  direction  and  supervision  over 
the  Army  automation  program.  He  functions  as  the  senior  Army  automatic  data 
processing  official  and  serves  as  a  member  of  the  ASARC.  He  has  cognizance 
over  Army  Regulation  18-1,  Management  Information  Systems  Policies,  Objectives, 
Procedures,  and  Responsibilities. 

(b)  Army  Staff. 

]_.  Assistant  Chief  of  Staff  for  Automation  and  Commu¬ 
nications  (ACSAC).  The  ACSAC  is  responsible  for  promulgation  of  Army 
automation  policy.  As  such,  he  is  the  Army  Staff  proponent  for  the  AR  18- 
series,  the  basic  Army  automation  policy  regulations.  He  is  responsible  for 
the  acquisition  of  commercial,  general  purpose  automatic  data  processing 
equipment  (ADPE),  and  services.  He  exercises  Army  Staff  supervision  over  the 
Computer  Systems  Command,  a  principal  system  developer. 

2.  Deputy  Chief  of  Staff  for  Research,  Development, 
and  Acquisition  (DCSRDA) .  The  DCSRDA  is  reponsible  for  Army  policy  relevant 
to  the  acquisition  of  all  materiel  resources,  including  computer  resources, 
except  for  commercial,  general  purpose  ADPE  as  noted  above.  He  has  Army 
Staff  responsibility  for  Research,  Development,  Test,  and  Evaluation  (RDTE) 
actions  involving  ADP  and  acts  as  the  approving  authority  for  development, 
deployment,  and  support  of  ADP  resources  for  tactical  computer  systems.  He 
is  the  Army  Staff  proponent  for  AR  1000-1  and  most  of  the  AR  70-series  per¬ 
taining  to  systems  research,  development,  acquisition  and  life  cycle  manage¬ 
ment. 


2-  Deputy  Chief  of  Staff  for  Operations  and  Plans  (DCS0PS). 
The  DCS0PS  responsibilities  include  validating  and  establishing  priorities 
for  Army  systems  and  establishing  Army-wide  automation  priorities.  He  is 
the  Army  Staff  proponent  for  command  and  control  systems.  He  develops  policy 
guidance  for  materiel  requirements  documents  associated  with  the  materiel 
acquisition  process  for  embedded  computer  resources  and  provides  guidance 
for  the  user  test  program.  He  is  the  Army  Staff  proponent  for  Army  Regula¬ 
tion  71-1:  Army  Combat  Developments. 

4.  Deputy  Chief  of  Staff  for  Logistics  (DCSL0G).  The 
DCSL0G  responsibilities  include  development  of  Army  policy  for  integrating 
logistics  support  and  maintenance  engineering  considerations  into  the 
materiel  system  life  cycle.  He  has  Army  Staff  responsibility  for  automated 
logistics  management  information  systems  in  support  of  all  assigned  functional 
areas  of  responsibility. 
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5_.  Deputy  Chief  of  Staff  for  Personnel  (DCSPER).  The 
DCSPER  has  Army  Staff  res  ansibility  for  automated  management  information 
systems  of  all  assigned  functional  areas  of  responsibility.  He  has  respond- 
sibility  for  developing  personnel  systems  to  meet  the  needs  of  new  or  improved 
doctrine,  organization,  and  materiel. 

6_.  Assistant  Chief  of  Staff  for  Intelligence  (ACS I ) .  The 
ACSI  has  Army  Staff  responsibility  for  establishing  threat  validation  policies 
and  standards,  and  exercising  ultimate  Army  threat  validation  authority.  He 
directs  the  functional  management  of  all  intelligence  and  security  automation 
to  include  intelligence  and  security  systems  which  are  functionally  integrated 
at  all  command  levels  and  which  support  the  wartime  mission  of  the  Army. 

7_.  The  Surgeon  General  (TSG).  The  Surgeon  General  issues 
instructions  governing  the  acquisition  and  management  of  automated  medical 
systems.  He  exercises  direction,  proponency,  evaluation,  and  coordination  of 
all  medical  automation  systems  of  the  Army. 

(c)  Field  operating  agencies. 

1_.  United  States  Army  Computer  Systems  Command  (CSC).  CSC 
is  the  central  design  agency  for  standard  management  information  systems.  CSC 
operates  under  the  control  and  supervision  of  the  ACSAC.  CSC  is  responsible 
for  the  design,  development,  programming,  testing,  installation,  maintenance, 
and  improvement  of  Army  multicommand  automatic  data  processing  systems.  Areas 
of  responsibility  include  project  management,  development,  and  support  of 
worldwide  standard  multicommand  management  information  systems  (STAMMIS).  This 
responsibility  includes  most  systems  addressed  in  this  study  for  which  the  US 
Army  Logistics  Center  (LOGCEN)  or  the  US  Army  Soldier  Support  Center  (SSC)  has 
functional  proponency. 

2.  United  States  Army  Operational  Test  and  Evaluation 
Agency  (OTEA).  OTEA  exercises  responsibility  for  all  Operational  Testing  (OT) 
and  manages  Force  Development,  Testing,  and  Experimentation  (FDTE)  and  joint 
user  testing  for  the  Army.  OTEA  operates  under  supervision  of  the  Office  of  the 
Chief  of  Staff.  OTEA  determines  when,  where,  how,  and  by  whom  operational 
testing  will  be  accomplished  for  all  major  and  selected  nonmajor  systems. 

Usually,  OT  is  conducted  by  OTEA  for  major  and  selected  nonmajor  systems  and  by 
TRADOC  or  another  designated  operational  tester  for  other  non-major  systems. 

3.  United  States  Army  Military  Personnel  Center  (MILPERCEN). 
MILPERCEN  is  a  Field  Operating  Agency  under  the  supervision  of  the  Deputy  Chief 
of  Staff  for  Personnel.  MILPERCEN  is  responsible  for  executing  and  recommending 
military  personnel  policies,  systems,  and  programs,  and  for  developing  and  super¬ 
vising  procedures  applicable  to  military  personnel  management  and  development  and 
to  support  services  to  include  personnel  information  systems  in  support  of 

the  soldier  and  the  chain  of  command.  MILPERCEN  is  designated  as  the  pro¬ 
ponent  agency  for  the  Standard  Installation/Division  Personnel  System  (SIDPERS) 
and  SIDPERS  Wartime.  MILPERCEN  is  also  involved,  with  the  US  Army  Soldier 
Support  Center  and  CSC,  in  the  development  and  life  cycle  management  of  other 
systems  in  the  Administration  portion  of  the  Combat  Service  Support  BFA.  This 
rather  complex  relationship  and  current  responsibilities  of  both  MILPERCEN  and 
the  Soldier  Support  Center,  are  discussed  in  Paragraph  2-4. f. (2). 
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(d)  Major  commands. 

T_.  US  Army  Training  and  Doctrine  Command  (TRADOC). 

TRADOC  is  designated  a  major  command  (MACOM)  of  the  Department  of  the  Army 
and  operates  under  the  supervision  of  the  Army  Chief  of  Staff.  The  mission 
of  the  Commanding  General,  TRADOC,  includes: 

•  Develop  and  manage  training  programs  and  supervise  the  training 
of  individuals  of  the  Army 

•  Conduct  all  combat  developments  not  assigned  by  HQDA  to  other 
commands  and  agencies  and,  as  the  Army's  principal  Combat 
Developer,  guide,  coordinate,  and  integrate  the  total  combat 
development  effort. 

The  concept  of  operation  within  TRADOC  is  that  within  the  parameters  of 
HQDA  guidance,  TRADOC  will  accomplish  its  combat  development  mission  through 
functional  centers,  service  schools,  and  other  TRADOC  combat  development 
activities,  in  coordination  with  other  Army  commands  and  agencies.  The  CG, 
TRADOC,  has  a  broad  range  of  functional  responsibilities  in  the  areas  of 
training  and  combat  developments  related  to  systems  acquisition  and  support 
to  include: 

•  Conducting  conceptual  and  analytical  studies  to  support  the 
development  of  doctrine,  materiel  requirements,  organizations, 
and  functional  systems 

•  Conducting  field  experiments  and  participating  in  other  force 
development  tests  and  evaluations  to  support  and  validate 
concepts  and  studies  associated  with  development  of  doctrine, 
materiel  requirements,  organizations,  and  functional  systems 

•  Monitoring  development  testing  and  participating  in  or 
planning  and  conducting  operational  testing 

•  Developing  or  reviewing  and  evaluating  requirements  documents 

•  Incorporating  the  products  of  the  total  Army  combat  develop¬ 
ment  effort  and  other  development  efforts  into  doctrinal  and 
organizational  literature  ,and  publishing  or  preparing  this 
material  for  publication.  '' 

'  I 

2_.  US  Army  Materiel  Development  and  Readiness  Command 
(DARCOM).  DARCOM  is  designated  a  major  command  of  the  Army  and  operates 
under  the  supervision  of  the  Army  Chief  of  Staff.  The  mission  of  the  CG, 
DARCOM  includes  acting  as  the  primary  Materiel  Developer  with  responsibilities 
for  research  and  development;  configuration  management;  developmental  test 
and  evaluation;  integrated  logistics  support  planning  and  execution;  reli¬ 
ability,  availability,  and  maintainability  (RAM);  acquisition  or  procurement; 
production;  new  materiel  training;  distribution;  wholesale  requirements  deter¬ 
mination;  and  maintenance,  storage,  and  disposal  of  all  materiel  systems  for 
the  US  Army.  Among  the  functions  within  these  DARCOM  responsibilities  are 
those  of  addressing  the  materiel  and  training  needs  of  the  Combat  Developer 
and  ensuring  man-machine  interface,  and  ensuring  that  the  materiel  systems 
proposed  for  development  meet  these  needs  and  are  safe,  effective,  and 
efficient  systems. 


3.  US  Army  Intelligence  and  Security  Command  (INSCOM). 
INSCOM  is  a  major  command  of  the  Army,  operating  under  the  supervision  of 
the  Army  Chief  of  Staff.  The  CG,  INSCOM  responsibilities  include: 

a_.  Threat  analysis  to  support  materiel  acquisition 
and  combat  development  activities. 

b.  In  conjunction  with  TRADOC,  formulating  concepts 
and  doctrine  for  establishing  materiel  development  objectives  for  specific 
materiel  requirements  and  evaluation  of  equipment  developed  for  use  in 
tactical  electronic  warfare. 

£.  Formulating  intelligence-related  user  require¬ 
ments  for  tactical  data  systems  and  developing  computer-based  tactical 
electronic  warfare  systems  under  provisions  of  AR  1000-1. 

INSCOM' s  efforts  are  coordinated  with  those  of  the  US  Army  Intelligence 
Center  and  School  to  ensure  appropriate  interface  and  relationships  among 
intelligence  and  electronic  warfare  systems  at  all  levels. 

4.  US  Army  Communications  Command  (USACC).  USACC  is 
a  major  command  of  the  Army,  operating  under  the  supervision  of  the  Army 
Chief  of  Staff.  USACC  is  the  major  Army  command  responsible  for  providing 
nontactical  communications  for  the  Army.  In  addition,  USACC  is  responsible 
for  the  interface  between  tactical  and  nontactical  communications  systems. 

(2)  Battlefield  functional  area  components.  TRAJOC  is  organized 
the  way  the  Army  fights  —  by battlefield  functional  area.  Therefore,  it  is 
appropriate  to  address,  by  battlefield  functional  area,  the  organizations 
within  TRADOC  that  have  key  roles  in  planning  for  or  providing  PDSS  for  BAS. 
The  BFA  concept,  which  provides  for  the  logical  grouping  of  related  battle¬ 
field  systems  into  battlefield  functional  areas,  currently  recognizes  five 
BFA  and  two  additional  functional  areas  essential  to  effective  operations 
on  the  battlefield.  Figure  2-2  identifies  the  elements  of  this  BFA  concept. 
Each  of  these  areas  and  the  TRADOC  organizations  within  each  area,  are 
identified  in  Figure  2-3  and  are  discussed  in  the  paragraphs  that  follow. 

The  way  in  which  these  organizations  operate  at  present  in  planning  for  and 
providing  PDSS  to  BAS  is  discussed  in  Paragraph  2-4,  Functional  Area  Analysis 

(a)  Force  Level  Control . 

1_.  As  indicated  in  Figure  2-2,  Force  Level  Control  is 
not  one  of  the  five  recognized  BFA,  but  rather  it  is  that  process  through 
which  a  commander  exercises  his  authority  in  directing,  monitoring,  and 
integrating  the  effort  of  all  organizations  and  activities  in  all  BFA. 


Figure  2-2.  Elements  of  the  battlefield  functional  area  concept 
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Figure  2-3.  TRADOC  organizational  elements  with  key  PDSS 
responsibilities  at  the  BFA  level 
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2_.  Within  TRADOC,  the  Combined  Arms  Combat  Development 
Activity  has  proponency  for  this  functional  area.  Within  CACDA,  responsibi¬ 
lity  is  assigned  V  the  Army  Command  Control/Joint  Interoperability  of 
Tactical  Command  and  Control  Systems  Division  of  the  Command,  Control, 
Communications  and  Intelligence  Directorate. 

3_.  Another  key  organizational  component  concerned  with 
BAS  in  the  command  and  control  functional  area  is  the  TRADOC  System  Manager 
for  Force  Level  and  Maneuver  Control  (SIGMA)  System  (TSM  SIGMA).  The  TSM 
SIGMA  is  responsible  for  exercising  management  of  the  SIGMA  system  within 
TRADOC.  The  TSM  SIGMA  office  is  not  currently  active. 

4.  Responsibilities  and  present  operating  procedures  of 
these  organizational  elements  related  to  Command  and  Control  BAS  are 
discussed  in  Paragraph  2-4. b. 

(b)  Fire  Support  battlefield  functional  area.  This  is 
the  BFA  which  is  the  major  contributor  of  fire  support  to  maneuver  forces. 
Within  TRADOC,  the  US  Army  Field  Artillery  Center  has  proponency  for  this 
BFA.  Field  Artillery  Center  organizational  elements  with  key  responsibilities 
in  the  development,  life  cycle  management,  and  post-deployment  support  of 

BAS  in  this  BFA  and  the  responsibilities  and  operations  of  these  organizations 
at  present  with  respect  to  providing  PDSS  for  Field  Artillery  BFA  BAS  are 
discussed  in  Paragraph  2-4. c. 

(c)  Air  Defense  battlefield  functional  area.  This  is  the 
BFA  responsible  for  reacting  to  and  defeating  enemy  aircraft  and  the  counter¬ 
measures  threat  under  all  environmental  and  tactical  conditions  in  all 
intensities  of  combat.  The  US  Army  Air  Defense  Center  has  proponency  for 

this  BFA.  Air  Defense  Center  organizational  elements  with  key  responsibilities 
in  the  development,  life  cycle  management,  and  post-deployment  support  of 
BAS  in  this  BFA  and  the  responsibilities,  and  current  operations  of  these 
organizations  with  respect  to  planning  for  and  providing  PDSS  for  Air  Defense 
BFA  BAS  are  discussed  in  Paragraph  2-4. d. 

(d)  Intelligence  and  Electronic  Warfare  battlefield  functional 

area.  - 


1_.  The  intelligence  portion  of  this  BFA  assists  the 
commander  and  his  staff  in  knowing  and  understanding  the  enemy  and  in  seeing 
the  battlefield.  The  electronic  warfare  element  of  the  BFA  is  responsible 
for  attacking  or  defending  systems  that  employ  electromagnetic  energy,  in¬ 
cluding  command  and  control,  weapon,  and  acquisition  systems.  The  U.S.  Army 
Intelligence  Center  and  School  is  the  TRADOC  proponent  for  this  BFA. 
Intelligence  Center  and  School  organizational  elements  with  key  reponsibilities 
in  the  development,  life  cycle  management,  and  post-deployment  support  of 
BAS  in  this  BFA  include: 


•  Directorate  of  Combat  Developments 

•  Directorate  of  Training  Developments 

•  TSM  for  Specified  Corps  Tactical  EW/Intell igence  Systems 

•  TSM  for  Specified  Division  Tactical  EW/Intell igence  Systems 

•  TSM  for  Stand-Off  Target  Acquisition  System 

•  Simulation  Systems  Management  Office 

2.  Within  the  Directorate  of  Combat  Developments,  the 
All-Source  Analysis  System  Management  Office  (ASAS  MO)  serves  as  the  focal 
point  for  all  actions  relating  to  this  key  intelligence  system,  and  supports 
the  TSM  ASAS,  located  in  CACDA,  as  required.  Further  discussion  of  the 
responsibilities  and  current  operations  of  these  organizations  in  planning 
for  and  providing  PDSS  to  Intelligence  and  EW  BAS  is  contained  in  Paragraph 
2-4. e. 

(e)  Combat  Service  Support  battlefield  functional  area. 

1_.  The  two  major  components  of  this  BFA  are  logistics 
and  administration.  The  logistics  portion  of  this  BFA  supports  decision 
making  of  each  tactical  echelon  by  providing  decisive  and  timely  logistic 
and/or  technical  expertise  as  far  forward  as  possible  to  give  the  tactical 
command  a  full  complement  of  operating  equipment  and  weapons.  The  admini¬ 
stration  portion  of  the  BFA  supports  the  commander  in  seeing  the  battlefield 
(friendly  personnel  situation)  and  in  sustaining  the  forces.  Assistance  and 
support  is  also  provided  to  other  BFA  and  to  the  soldiers  who  man  them. 

The  US  Army  Logistics  Center  is  the  TRADOC  pro¬ 
ponent  for  the  logistics  portion  of  the  Combat  Service  Support  (CSS)  BFA. 
Within  the  Logistics  Center,  the  Management  Information  Systems  Directorate 
has  primary  responsibility  for  developing  and  coordinating  the  functional 
plans,  design,  installation,  maintenance,  and  customer  assistance  for 
logistics  BAS  in  the  CSS  BFA. 

b_.  The  US  Army  Soldier  Support  Center  is  the 
TRADOC  proponent  for  the  administration  portion  of  the  CSS  BFA.  The  CG, 
Soldier  Support  Center  is  responsible  for  developing  and  coordinating  the 
functional  design,  evaluation,  and  extension  of  battlefield  administration 
management  information  systems  applicable  to  the  corps  level  and  below. 
Within  the  Soldier  Support  Center,  this  responsibility  is  assigned  to  the 
Directorate  of  Combat  Developments,  US  Army  Institute  of  Personnel  and 
Resource  Management. 

2_  Details  of  the  organizations  involved  with  battle¬ 
field  automated  systems  at  the  Logistics  Center  and  Soldier  Support  Center 
and  the  current  operating  procedures  related  to  PDSS  within  each  command  are 
discussed  in  Paragraphs  2-4.f.(l)  and  (2),  respectively. 


* 
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(f)  Maneuver  battlefield  functional  area.  This  8FA, 
through  its  inherent  subsystems  of  direct  fire  (including  subelements  of 
infantry,  armor,  Army  aviation,  and  air/ground  systems),  engineer,  and 
integration,  provides  the  timely  means  to  generate  and  apply  decisive  combat 
power  on  the  modern  battlefield.  CACDA  has  overall  proponency  for  the 
Maneuver  BFA  and  is  responsible  for  coordinating  and  integrating  the 
activities  of  the  US  Army  Infantry  Center  and  School,  the  US  Army  Armor 
Center  and  School,  the  US  Army  Aviation  Center  and  the  US  Army  Engineer 
Center  in  their  respective  areas  of  responsibility.  Within  CACDA,  this 
reponsibil ity  is  assigned  to  the  Directorate  of  Concepts  and  Doctrinal 
Management.  Further  discussion  of  this  BFA  is  contained  in  Paragraph  2-4. g. 

(g)  Communications  functional  area. 

1_-  As  illustrated  in  Figure  2-2,  conmmuni cations  is 
not  one  of  the  five  currently  recognized  BFA,  but  rather  it  is  that  mechanism 
through  which  the  commander  directs  and  controls  all  other  battlefield 
functions  in  the  performance  of  his  mission.  Communications  impacts  on  and 
is  impacted  by  all  BFA. 

2.  Within  TRADOC,  the  US  Army  Signal  Center  and  School 
is  the  proponent  for  the  communications  functional  area.  CACDA  has  respon¬ 
sibility  for  coordinating  the  integration  of  actions  in  the  communication: 
area  with  those  in  other  BFA.  Further  discussion  of  the  Signal  Center's 
organizational  elements  and  current  operations  related  to  PDSS  for 
communications  BAS  is  presented  in  Paragraph  2-4. h. 

b .  Regulatory  Policy  and  Procedures. 

(1 )  General . 

(a)  The  policy  governing  the  acquisition  and  life  cycle 
management  of  computer  resources  in  the  Army  is  divided  between  AR  18-1, 
for  which  the  ACSAC  is  responsible,  and  ARs  70-1  and  1000-1,  which  are  the 
responsibility  of  DCSRDA.  AR  18-1  was  revised  and  published  in  August  1980 
and  is  to  be  accompanied  by  a  series  of  implementing  Technical  Bulletins. 

ARs  70-1  and  1000-1  are  currently  under  revision. 

(b)  In  connection  with  these  revisions,  efforts  are  being 
made  to  clarify  the  applicability  of  each  regulation,  and  to  harmonize  the 
different  system  life  cycle  models  and  other  provisions  which  they  contain. 
Additionally,  greater  emphasis  is  being  placed  on  addressing  requirements 
for  system  support  following  deployment.  The  final  result  of  the  efforts  to 
revise  ARs  70-1  and  1000-1  and  accomplish  the  objectives  referred  to  above 
is  not  known  at  this  time  since  both  ARs  are  still  in  draft  and  AR  18-1  has 
just  been  published.  However,  a  review  of  portions  of  drafts  of  each  regula¬ 
tion  indicates  needed  improvements  are  being  addressed. 
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(c)  These  three  basic  regulations  and  several  other  key 
Department  of  Defense,  Department  of  the  Army,  and  Major  Command  regulatory 
documents  relative  to  system  acquisition  and  life  cycle  management  (including 
PDSS)  arc  identified  and  discussed  briefly  below.  Additional  regulatory  and 
directive  documents  are  identified  in  Appendix  A. 

(2)  Department  of  Defense. 

(a)  DODD  5000. 1 :  Major  System  Acquisition.  Washington,  D.C. 
19  March  1980.  (This  DOD  Directive  cancels  DODD  5000.1,  18  January  1977 
and  DODD  5000.2,  18  January  1977.) 

This  directive  implements  for  the  Department  of  Defense 
the  concepts  and  provisions  of  Office  of  Management  and  Budget  (0MB) 

Circular  A-109,  5  April  1976,  and  applies  to  the  acquisition  of  major  systems 
Principles  of  this  directive  are  to  also  be  applied  to  other  systems  not 
designated  as  major. 


Among  other  things,  this  directive  lists  as  objectives: 

1_.  Ensuring  that  an  effective  and  efficient  acquisition 
strategy  is  developed  and  tailored  for  each  system  acquisition  program. 

2.  Minimizing  the  time  from  need  identification  to 
introduction  of  each  system  into  operational  use. 


2-  Integrating  support,  manpower,  and  related  concerns 
and  activities  into  the  acquisition  process. 

This  directive  also  establishes  the  milestone  decisions 
and  phases  of  activity  in  the  acquisition  process  and  specifies  the  principal 
documentation  needed  to  support  each  milestone  decision. 

(b)  DODI  5000.2:  Majc  '  .ystem  Acquisition  Procedures. 
Washington,  D.C.:  19  March  1980.  (This  DOD  Instruction  replaces  DODD 

5000.2,  18  January  1977.) 

This  instruction  provides  supplementary  procedures  for 
Department  of  Defense  use  in  implementing  DODD  5000.1,  19  March  1980. 
Paragraph  12  states  that  acquisition  of  embedded  computer  resources  for 
operational  military  systems  (including  command  and  control  systems)  shall 
be  managed  within  the  context  of  the  total  system.  It  provides  that: 

1_.  Requirements  for  interfaces  between  computers  and 
plans  to  achieve  that  interface  must  be  identified  early  in  the  life  cycle. 


2.  Plans  for  software  development,  documentation, 
testing,  and  update  during  deployment  and  operation  require  special  attention 


2-  Computer  resource  planning  shall  be  accomplished 
before  Milestone  II  and  continue  throughout  the  system  life  cycle. 

4.  Computer  hardware  and  software  shall  be  treated  as 
configuration  items  I’d) . 

Paragraph  13  describes  an  alternate  evolutionary 
acquisition  management  procedure  for  command  and  control  systems  (which  meet 
certain  criteria)  that  would  allow  early  implementation  of  a  prototype  system 
using  existing  hardware  and  software.  The  prototype  system  would  then  be 
developed  further  through  an  evolutionary  process. 

(c)  DODD  5000.3:  Test  and  Evaluation.  Washington,  D.C.: 

26  December  1979. 

This  directive  establishes  policy  for  the  conduct  of 
test  and  evaluation  in  the  acquisition  of  defense  systems  designated  by 
the  Secretary  of  Defense  as  major.  Management  of  other  systems  (nonmajor) 
shall  also  be  guided  by  the  principles  set  forth  in  this  directive.  PDSS 
has  been  addressed  indirectly  in  this  directive.  It  provides  that  after 
Milestone  III: 

1_.  Development,  Test,  and  Evaluation  (DT&E)  shall  be 
an  integral  part  of  the  development,  acceptance,  and  introduction  of  systems 
changes  to  improve  the  system,  react  to  new  threats,  and  reduce  life  cycle 
costs. 

2.  The  DOD  Component  Operational  Test  and  Evaluation 
(OT&E)  agency  will  manage  follow-on  OT&E  as  necessary  to  ensure  that  the 
initial  production  items  meet  operational  effectiveness  and  suitability 
thresholds  and  to  evaluate  system  improvements  to  meet  mature  system 
readiness  and  performance  goals. 

(d)  DODD  5000.29:  Management  of  Computer  Resources  in  Major 

Defense  Systems.  Washington,  D.C.:  26  April  1976. 

This  Directive  establishes  policy  for  the  management  and 
control  of  computer  resources  during  the  development,  acquisition,  deployment, 
and  support  of  major  defense  systems.  It  provides  that  computer  resources  in 
defense  systems  must  be  managed  as  elements  or  subsystems  of  major  importance 
during  conceptual,  validation,  full-scale  development,  production,  deployment, 
and  support  phases  of  the  life  cycle,  with  particular  emphasis  on  computer 
software  and  its  integration  with  the  surrounding  hardware. 

(3)  Department  of  the  Army. 

(a)  AR  10-5:  Organization  and  Functions,  Department  of  the 
Army.  Washington,  D.C.:  1  November  1978. 
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This  regulation  sets  forth  the  organization  and  functions 
of  the  Department  of  the  Army  and  the  general  responsibilities  of  the  heads 
and  commanding  generals  of  its  major  elements.  It  addresses  the  Office  of 
the  Secretary  of  the  Army  and  the  Army  Staff.  Major  commands  are  identified 
but  their  organization  mission  and  functions  are  described  in  other  regulations 
in  the  AR  10-series. 

(b)  AR  10-11:  Organization  and  Functions,  US  Army  Materiel 

Development  and  Readiness  Command  (DARCOM).  Washington,  D.C.:  9  March  1977. 

This  AR  prescribes  the  mission  and  principal  functions 
of  the  Commanding  General,  DARCOM  and  sets  forth  command  and  staff  relation¬ 
ships  with  higher  and  collateral  headquarters.  For  all  classes  of  supplies, 
except  those  managed  by  other  agencies,  DARCOM  has  the  mission  to: 

1_.  Act  as  the  primary  materiel  developer. 

2.  Develop  and  provide  materiel  maintenance  and 
related  logistic  services  to  DA  and  other  agencies  as  directed. 

3_.  Provide  worldwide  technical  and  professional 
guidance  and  assistance  for  readiness  planning  and  logistical  support  for 
Army  materiel  in  coordination  with  US  Army  Logistics  Center  in  its  area  of 
responsibility. 

While  PDSS  is  not  specifically  addressed  in  this  AR,  the 
responsibility  for  PDSS  is  inherent  in  DARCOM' s  primary  mission  as  the  Army's 
principal  Materiel  Developer.  PDSS  is  also  included  within  DARCOM's  re¬ 
sponsibility  for  planning,  programming,  funding,  system  integration,  and 
implementation  of  the  Product  Improvement  Plan  (PIP). 

(c)  AR  1 0-41 :  Organization  and  Functions,  US  Army  Training 
and  Doctrine  Command  (TRADOC).  Fort  Monroe:  1  May  1980. 

This  AR  prescribes  the  mission  and  principal  functions 
of  the  CG  TRADOC  and  sets  forth  command  and  staff  relationshps  with  higher 
and  collateral  commands  and  agencies  of  the  US  Army.  One  of  TRADOC 's 
missions  is  to  conduct  all  combat  development  not  assigned  by  HQDA  to  other 
commands,  and  as  the  Army's  principal  Combat  Developer,  to  guide, 
coordinate,  and  integrate  the  total  combat  development  effort  of  the  Army. 

In  furtherance  of  TRADOC' s  mission  as  the  Army’s  principal  Combat  Developer, 

CG  TRADOC  is  authorized  and  required  to  task  and  provide  parameters  and 
guidance  to  other  Army  Commands  and  agencies  having  combat  development 
functions  assigned  by  HQDA  and  to  integrate  the  resultant  products  into  the 
overall  combat  development  effort.  While  there  is  no  specific  assignment  of 
PDSS  responsibility,  PDSS  functions  are  inherent  in  the  mission  described 
above. 
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(d)  AR  18-1 :  Army  Automation,  Army  Automation  Management. 

Washington,  D.C.:  15  August  1980. 

This  regulation  and  implementing  TBs  prescribe  policies 
and  responsibilities  and  delegate  authority  for  the  management  of  Army 
automation.  This  regulation  does  not  apply  to  computers  and  other  automatic 
data  processing  equipment  integral  to  a  combat  weapon  system.  Computer- 
based  tactical  systems  that  provide  combat  or  combat  support  assistance  are 
acquired  and  managed  under  AR  1000-1  and  AR  70-1.  Software  development  and 
support  associated  with  computer  elements  of  combat  weapons  systems  also 
fall  within  the  scope  of  AR  70-1  and  project  manager  charters. 

AR  18-1  prescribes  a  new  system  life  cycle  which  re¬ 
cognizes  five  distinct  phases--project  initiation,  concept  development, 
definition/design,  system  development,  and  deployment--and  places  added 
emphasis  on  the  deployment  (and  post-deployment)  period  in  the  life  cycle. 
This  is  an  effort  to  harmonize  the  life  cycles  prescribed  by  AR  18-1,  AR 
70-1,  and  AR  1000-1. 

(e)  AR  1000-1 :  Basic  Policies  for  Systems  Acquisition, 

1  April  1978.  (This  AR  is  being  revised.  The  revision  will  implement  the 
revised  DODD  5000.1,  19  March  1980  and  D0DI  5000.2,  19  March  1980.) 

This  regulation  establishes  basic  Army  policy  for 
acquisition  of  materiel  systems  and  together  with  AR  70-15  implements  the 
18  January  1977  DODDs  5000.1  and  5000.2.  The  general  principles  of  AR 
1000-1  apply  to  the  development  and  acquisition  of  all  Army  materiel  systems, 
including  those  multi-service  programs  for  which  DA  is  the  lead  service. 

It  describes  the  system  acquisition  process  and  the  responsibilities  at  the 
macro-management  level  for  the  Army  Secretariat,  DA  Staff,  DARC0M,  TRAD0C, 
USACC  and  other  Department  of  the  Army  agencies.  This  regulation  is  not 
applicable  to  automatic  data  processing  equipment,  services,  or  supplies 
that  come  under  the  purview  of  AR  18-1. 

(f)  AR  70-1 :  Research  and  Development,  Army  Research, 
Development,  and  Acquisition,  1  February  1977.  (This  regulation  is  currently 
being  revised.) 


This  regulation  implements  DODD  5000.1  (18  January 
1977),  and  AR  1000-1  (1  February  1977)  as  they  apply  to  research,  development 
and  acquisition  of  new  systems  and  equipment.  This  regulation  establishes 
responsibilities,  policy,  and  general  procedures  for: 

1_.  Conducting  research  and  development  in  DA. 

2.  Acquiring  developmental,  nondevelopmental  items,  or 
systems  to  satisfy  HQDA  approved  requirements  for  materiel  systems. 
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3^.  Conduct  of  developmental  product  improvements  to 
satisfy  HQDA  approved  requirements  for  materiel  systems. 

A  new  chapter,  "Research,  Development,  and  Acquisition 
of  Battlefield  Automated  Systems,"  is  being  added  to  the  revised  AR  70-1. 

This  chapter  will  apply  to  computer  resources  in  all  systems  managed  under 
AR  1000-1  and  the  AR  70-series  of  regulations  whether  the  systems  are  major 
or  nonmajor.  It  will  implement  DODD  5000.29,  and  provide  for  cost  effective 
life  cycle  management  of  computer  resources  in  systems  managed  under  AR  1000-1. 
It  will  apply  to  BAS  and  embedded  (integral  and  direct  support)  computer 
resources  as  defined  by  the  revised  AR  18-1. 

(g)  AR  70-15:  Research  and  Development,  Product  Improvement 
of  Materiel,  15  June  1980. 

The  purpose  of  this  AR  is  to  set  policies  and  procedures 
for  the  management  of  product  improvement  (PI).  It  specifically  applies  to 
all  Army  developing  agencies  and  project  managers  or  activities  that  use  or 
give  logistic  support  for  operational  systems.  Included  in  the  wide  variety 
of  product  improvements  made  under  this  program  are  computer  software  changes 
of  battlefield  automated  systems  (BAS),  managed  under  AR  1000-1,  which 
expand  the  system  performance  envelope. 

Ideas  for  PI  may  come  from  the  User,  Combat  Developer, 
Trainer,  Logistician,  Industry,  other  Service  Users,  or  Materiel  Developer. 

The  idea  must  first  be  coordinated  with  the  CD  and  then  the  MD  (who  is 
assigned  technical  proponency  for  the  end  item). 

(h)  AR  70-37:  Configuration  Management.  Washington,  D.C.: 

19  July  1976. 

This  AR  prescribes  uniform  policies  and  guidance  for  the 
Military  Services  and  Defense  Agencies  responsible  for  implementation  of 
Configuration  Management  within  the  Department  of  Defense.  It  applies  to: 

1_.  Major  defense  systems  under  DODD  5000.1. 

2.  Other  designated  systems  (less  than  major  programs) 
requiring  Service/Agency  decision  processing. 

2-  Selected  end  item/prime  equipments  for  reason  of 
systems  integration  or  interface  control. 

One  of  the  objectives  of  this  AR  is  to  ensure  that  the 
configuration  of  configuration  items  (Cl)  for  operational  and  nonoperational 
use  is  known  and  pertinent  physical  and  functional  interfaces  between  systems, 
equipments,  and  computer  programs  are  documented  and  controlled.  During  the 
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Deployment/Operational  Phase  of  the  life  cycle,  configuration  items  (Cl)  will 
be  subject  to  configuration  management  and  integrated  with  modification  manage¬ 
ment  throughout  the  Cl's  life  cycle  until  the  Cl  is  removed  from  the  DOD 
inventory. 


(i)  AR  71-3:  Force  Development  User  Testing.  Washington, 
D.C.:  8  March  1977. 


The  purpose  of  this  AR  is  threefold: 

1_.  To  establish  policies  and  procedures  and  assign  respon¬ 
sibilities  for  initiating,  planning,  programming,  conducting,  and  reporting  User 
testing. 


2.  To  describe  responsibilities,  functions,  and 
procedures  of  the  DA  Test  Schedule  and  Review  Committee  (TSARC). 

3^  To  govern  operational  testirg  (OT),  force  development 
testing  and  experimentation  (FDTE),  and  joint  User  testing. 

OT  and  FDTE  are  used  to  support  the  materiel  acquisition 
process.  The  principles  of  this  regulation  apply  to  product  improvements 
and,  thus,  to  PDSS. 

(j)  AR  700-127:  Logistics,  Integrated  Logistic  Support. 

Washington,  D.C.:  11  April  1975. 

This  regulation  implements  DOD  Directive  4100.35  and 
establishes  US  Army  Policy  for  integrating  life  cycle  logistic  support  con¬ 
siderations  into  the  materiel  acquisition  process.  It  is  applicable  to: 

1_.  All  developmental,  nondevelopmental ,  and  product-impro¬ 
ved  Army  materiel  systems,  to  include  support  equipment  and  training  devices. 

2.  All  Army  commands  and  agencies  having  responsibility 
for  materiel  development,  combat  development,  training,  test  and  evaluation, 
materiel  management  and  other  aspects  of  logistic  support  to  include 
ballistic  defense  systems. 

(k)  DA  Pamphlet  11-25:  Life  Cycle  System  Management  Model 

for  Army  Systems.  Washington,  D.C.:  21  May  1975. 

Illustrated  in  this  pamphlet  is  the  flow  chart  of  the  Life 
Cycle  System  Management  Model  (LCSMM)  by  which  Army  materiel  systems  are  initi¬ 
ated,  validated,  developed,  deployed,  supported  and  modified.  The  principles  and 
general  acquisition  guidelines  may  also  be  applied  to  nonmateriel  systems  acqui¬ 
sition  when  applicable.  This  pamphlet  will  require  revision  to  implement 
changes  in  revised  ARs  1000-1  and  70-1,  discussed  in  (e)  and  (f),  above. 

(l )  Memorandum  from  the  Assistant  Secretary  of  the  Army  (RDA). 

Standardization  of  Embedded  Computer  Resources.  Washington,  D.C.:  1  July  1980. 

This  memorandum  issues  policy  for  standardization  of  pro¬ 
gramming  language  and  hardware  for  Battlefield  Automated  Systems  (BAS).  This 
policy  provides  that: 
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•  Ada  and  its  associated  software  development  environment  will  be  used 
in  all  new  software  developments  or  major  modifications  to  BAS  soft¬ 
ware  developments  starting  after  January  1980 

•  A  single  standard  Instruction  Set  Architecture  (ISA)  will  be  adopted 
by  the  Army  in  1981  and  will  be  used  in  all  systems  entering  Advanced 
Development  in  1983 

t  All  BAS  entering  Engineering  Development  in  1984  will  use  the  standard 
Military  Computer  Family  (MCF)  hardware. 

This  memorandum  applies  to  embedded  computer  resources  and  systems  developed 
under  the  provisions  of  AR  1000-1  and  the  AR  70-Series.  It  applies  to  all 
functions  which  are  integral  to  BAS  regardless  of  the  type  of  system  such  as  fire 
control,  command  and  control,  or  administration/logistics.  This  policy  memorandum 
was  promulgated  within  TRADOC  by  a  letter  from  the  Office  of  the  Deputy  Commander, 
file  ATDC,  subject:  Standardization  of  Embedded  Computer  Resources,  30  July  1980. 
This  letter  states  that,  "In  particular,  all  Combat  Service  Support  BAS  "intended 
for  use  by  the  Army  in  the  field"  will  be  developed  and  procured  under  AR 
1000-1  and  the  AR  70-Series  vice  the  traditional  AR  18-1  approach". 

(4)  Major  Command. 

(a)  TRADOC  Regulation  10-5:  Organization  and  Functions. 

Fort  Monroe:  10  December  1979. 

This  TRADOC  regulation  defines  the  organization  of  HQ  TRADOC 
and  delineates  staff  organization,  responsibilities  and  functions.  One  of  the 
stated  policies  is  that  operational  control  of  mission  activities  will  be  decen¬ 
tralized  to  TRADOC' s  integrating  centers,  installations,  and  specialized 
activities  to  the  maximum  possible  extent.  The  HQ  TRADOC  staff  includes  the 
Deputy  Chief  of  Staff  for  Combat  Developments.  Subordinate  to  the  Deputy  Chief 
of  Staff  for  Combat  Developments  is  the  Telecommunications,  Command  and  Control, 
and  Computer  Systems  Directorate.  This  directorate  is  responsible  for  the 
tactical  data  systems  automation  management  function  for  HQ  TRADOC. 

(b)  TRADOC  Regulation  10-41:  Organizations  and  Functions, 

Mission  Assignments.  Fort  Monroe:  1  May  1980. 

This  regulation  prescribes  missions  and  principal  functions 
of  the  major  elements  of  TRADOC,  and  sets  forth  command  and  staff  relationships 
within  TRADOC  and  with  higher  and  lateral  commands.  Within  the  major  TRADOC 
function  of  combat  development  is  the  task  to  develop  requirements  statements 
for  materiel  systems.  These  statements  must  accurately  specify  performance 
characteristics  dictated  by  operational  concepts  for  modern  battle  fighting  and 
will  be  specified  in  terms  of  personnel  mental  and  physical  capabilities.  The 
task  also  includes  the  translation  of  these  requirements  into  materiel  acquisi¬ 
tion  programs  to  equip  the  Army  with  resultant  systems  as  rapidly  as  possible. 

(c)  DARCOM-TRADOC  Materiel  Acquisition  Handbook:  Advance  Copy, 


1  January  1980. 


2-19 


This  jointly  prepared  handbook  describes  policies,  procedures, 
documentation,  and  responsibilities  for  implementing  the  materiel  acquisition 
concept  contained  in  ARs  1000-1  and  70-1.  Its  primary  thrust  is  to  provide 
guidance  at  the  action  officer  level  for  accomplishing  each  principal  action  in 
the  materiel  acquisition  process. 

(d)  DARCOM  Regulation  70-16:  Management  of  Computer  Resources 
in  Battlefield  Automated  Systems.  Alexandria,  V A:  16  July  1979. 

This  regulation  implements  DODD  5000.29.  It  establishes 
policy  and  assigns  responsibilities  for  planning,  development,  acquisition, 
testing,  training  and  support  of  major  and  nonmajor  Army  battlefield  automated 
systems  employing  computer  resources.  The  systems  subject  to  the  provisions  of 
this  regulation  are  those  that  employ  computer  resources  and  operate  or  have 
components  that  operate  within  the  boundaries  of  the  battlefield  (Army  Battle¬ 
field  Automated  Systems).  The  objective  is  to  ensure  that  computer  resources 
in  Army  BAS  are  planned,  developed,  tested,  acquired,  fielded,  and  supported 
in  a  cost  effective  and  timely  manner.  This  regulation  specifies  that: 

JL  During  the  Demonstration  and  Validation  Phase  of 
system  acquisition,  a  Computer  Resource  Management  Plan  (CRMP)  will  be  prepared 
for  each  Army  BAS,  identifying  important  computer  resource  acquisition  and  life 
cycle  planning  factors  and  establishing  specific  guidelines  to  ensure  that 
these  factors  are  adequately  considered  in  the  acquisition  planning  process. 

It  will  be  prepared  by  the  Materiel  Developer,  in  coordination  with  the  Combat 
Developer,  Development  and  Operational  Testers,  Development  and  Operational 
Evaluators,  and  the  designated  readiness  activity. 

2.  Army  battlefield  automated  system  computer  resources, 
including  both  computer  hardware  and  computer  software,  will  be  specified 
and  treated  as  configuration  items.  The  Configuration  Control  Board  (CCB) 
will  be  the  primary  medium  for  managing  hardware  and  software  control  and 
release  throughout  the  remaining  system  life  cycle. 

c.  Battlefield  Automated  Systems  Supported.  The  third  major  component 
of  the  current  post-deployment  software  support  system  analyzed  during  this 
study  is  the  BAS  supported  within  each  BFA. 

(1)  BAS  definition.  For  purposes  of  this  study,  the  definition 
of  battlefield  automated  system  contained  in  the  PDSS  Concept  Plan  for  BAS 
was  used.  This  definition  states: 

Battlefield  Automated  System  (BAS)  -  A  system  employing  computer 
resources  that  operates  or  has  components  that  operate  within  the 
boundaries  of  the  battlefield,  regardless  of  the  function,  mission, 
or  battle  involvement.  The  system  may  be  an  offensive,  defensive, 
or  direct/indirect  support  system.  Examples  of  such  systems  are 
weapons,  communications,  command  and  control,  intelligence,  avionics, 
missiles,  combat  support  and  combat  service  support  systems. 

(2)  BAS  addressed  in  this  study. 

(a)  In  the  DARCOM-initiated  study  effort  conducted  to  develop 
the  PDSS  Concept  Plan  for  BAS,  110  such  systems  including  91  DARCOM  systems  and 
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19  CSC-developed/maintained  systems  were  identified.  The  DARCOM  systems  were 
categorized  during  that  study  effort  based  on  their  size  (lines  of  code)  and 
likelihood  of  change  as  explained  in  Appendix  C.  Specific  categories  establi¬ 
shed  were: 

•  Category  1  -  large  evolutionary  systems 

•  Category  2A  -  small  evolutionary  systems 

•  Category  2B  -  large  stable  systems 

•  Category  3  -  small  stable  systems 

This  categorization  effort  resulted  in  identifying  6  systems  as  Category  1,  27 
as  Category  2,  and  58  as  Category  3.  The  CSC  systems  were  not  categorized. 

(b)  Research  conducted  during  Phase  I  of  this  current  TRAD0C- 
sponsored  PDSS  study  has  resulted  in  some  modifications  to  the  listing  of  the 
110  BAS  referred  to  above.  Seven  of  the  110  BAS  have  been  deleted  from  further 
consideration  during  this  study  because  the  programs  have  been  discontinued  and 
six  have  been  added  for  reasons  discussed  in  Paragraph  2-4  and  Chapter  3.  This 
results  in  a  modified  listing  of  109  BAS  identified  for  further  consideration 
during  this  study.  Figure  2-4  shows  a  breakdown  of  these  BAS  by  category 
within  each  BFA  or  functional  area.  Appendix  C  provides  a  listing  of  all 
Category  1,  2  and  3  systems  and  the  CSC-developed  BAS  organized  by  BFA.  It 
also  identifies  the  category,  proponent,  developing  command,  readiness  command, 
and  projected  PDSS  center  for  each  of  these  BAS. 

(c)  While  all  109  BAS  will  continue  to  be  addressed  to  some 
extent  during  this  study,  the  Study  Advisory  Group  (SAG)  guidance  provides 
that  the  Study  Team's  effort  should  be  focused  primarily  on  Category  1  and 
2  and  CSC  systems.  This  guidance  results  from  TRADOC  being  principally 
concerned  with  software  in  these  large  and/or  evolutionary  systems.  Software 
in  Category  3  systems  is  not  expected  to  change  significantly  once  the  system 
is  fielded.  Thus,  primary  effort  during  the  remainder  of  this  study  will  be 
focused  on  the  29  Category  1  and  2  systems  and  the  22  CSC  systems  identified 
in  Appendix  C. 

2-3.  MACRO-MANAGEMENT  LEVEL  ANALYSIS. 

a.  General .  This  paragraph  contains  a  discussion  and  analysis  of 
the  macro-management  level  PDSS  system.  The  macro-management  level 
organizations  identified  in  Paragraph  2-2. a. (1),  the  applicable  regulatory 
documents  discussed  in  2-2. b. ,  and  organizational  responsibilities, 
relationships,  and  operating  procedures  are  addressed. 

b.  Role  of  Macro-Management  Level  Structure.  The  role  of  the  Army 
macro-management  level  structure  with  respect  to  PDSS  for  BAS  is  primarily 
one  of  establishing  and  promulgating  applicable  policy  and  guidance,  and 
acquiring  and  allocating  resources  necessary  to  provide  effective  post¬ 
deployment  support  to  battlefield  systems.  This  role  is  carried  out  at  the 
Headquarters,  Department  of  the  Army  and  major  command  levels. 
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Figure  2-4.  BAS  by  category  and  functional  area 


c.  Organizations  Involved.  The  specific  Army  Staff  elements  and 
other  organizations  addressed  in  this  study  at  the  macro-management  level 
were  identified  in  Figure  2-1  and  discussed  briefly  in  Paragraph  2-2. a., 
along  with  their  missions  and  principal  responsibilities  associated  with 
systems  acquisition  and  life  cycle  management.  No  significant  gaps  or 
duplications  were  identified  among  the  mission/responsibility  statements 
of  these  organizations.  No  changes  appear  to  be  needed  in  organizational 
missions  pertaining  to  systems  acquisition  and  life  cycle  management  at 
the  macro-management  level.  However,  AR  10-5:  Organization  and  Functions, 
Department  of  the  Army,  needs  to  be  revised  and  republished  to  clarify  the 
responsibilities  of  the  ACSAC  and  the  relationship  between  the  ACSAC  and 
DCSRDA  in  this  functional  area.  The  Study  Team  agrees  with  the  statement 
in  the  PDSS  Concept  Plan  for  BAS,  May  1980,  that  the  current  missions  and 
functions  of  the  Army  Staff  and  MACOMs  form  an  acceptable  framework  for 
developing  an  effective  PDSS  system  for  BAS. 

d.  Current  Policy. 

(1)  Applicable  regulations.  Current  Army  policy  applicable  to 
system  acquisition  and  life  cycle  management  (to  include  post-deployment 
support  of  BAS)  is  contained  in  ARs  1000-1,  70-1,  and  18-1.  AR  1000-1 
contains  basic  policy  for  system  acquisition  and  life  cycle  management.  The 
AR  70-series  provides  additional  details  necessary  to  implement  AR  1000-1. 
These  regulations,  which  are  issued  under  the  proponency  of  DCSRDA  and 

the  control  of  the  Assistant  Secretary  of  the  Army  (Research,  Development 
and  Acquisition),  implement  the  basic  Department  of  Defense  and  Office  of 
Management  and  Budget  procurement  policies.  They  are  applicable  to  the 
acquisition  of  all  BAS  addressed  in  this  study  except  those  involving 
commercial,  general  purpose  automatic  data  processing  systems  which  must  be 
acquired  under  AR  18-1.  AR  18-1  governs  the  acquisition  of  these  latter 
systems,  in  accordance  with  D0D  directives  and  provisions  of  Public  Law 
89-306  (The  Brooks  Bill).  This  bill  prescribes  special  management  require¬ 
ments  and  procedures  intended  to  insure  the  economic  and  effective  purchase, 
lease,  maintenance,  operation,  and  utilization  of  commercial  ADP  equipment. 

The  ACSAC  is  the  Army  Staff  proponent  for  AR  18-1  which  is  under  the  super¬ 
vision  of  the  Assistant  Secretary  of  Defense  (Installations,  Logistics  and 
Financial  Management).  Thus,  two  separate  and  distinct  sets  of  policy 
documents  exist  (AR  1 000- 1 /AR  70-1  and  AR  18-1)  that  are  applicable  to  the 
acquisition  and  life  cycle  management  of  BAS. 

(2)  Implications.  This  dual  set  of  policy  documents  has 
implications  with  respect  to  the  BAS  addressed  in  this  study.  In  general, 
the  CSC-developed  systems  for  which  the  Logistics  Center  or  the  Soldier 
Support  Center  has  combat  developer  proponency  are  developed  under  provisions 
of  AR  18-1  while  other  BAS  are  developed  under  AR  1000-1  and  the  AR  70-series. 
However,  there  are  some  differences  of  opinion  regarding  the  applicability 
and  scope  of  these  regulations.  Efforts  are  being  made  through  the  recent 
revision  of  AR  18-1  and  the  revisions  currently  being  made  to  ARs  1000-1 

and  70-1  to  clarify  the  applicability  of  each  set  of  regulations  and  to 
harmonize  the  requirements  and  procedures  of  each.  To  the  extent  that  this 
effort  is  successful,  it  should  eliminate  problems  resulting  from  different 
interpretations  and  perceived  disparities  in  the  provisions  and  applicability 
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of  these  policy  documents  at  the  macro-management  level.  Also  bearing 
directly  on  this  subject  is  the  memorandum  from  the  Assistant  Secretary 
of  the  Army  (RDA),  1  July  1980,  subject:  Standardization  of  Embedded 
Computer  Resources,  and  the  implementing  letter  from  the  Deputy  Commander, 
TRADOC,  30  July  1980,  both  of  which  were  cited  in  Paragraph  2-2. b. ( 2 ) ( 1 ) . 
When  implemented,  the  policy  and  guidance  contained  in  these  two  documents 
will  provide  for  more  standardized  system  development  procedures  within 
TRADOC. 


(3)  Adequacy.  A  serious  inadequacy  of  Army  regulatory  documents 
has  been  that  while  purporting  to  address  the  entire  life  cycle  of  a  system 
from  initiation  through  development  and  deployment  to  eventual  disposal  upon 
obsolescense,  little  emphasis  is  placed  on  post-deployment  support  in  general 
or  on  post-deployment  software  support  in  particular.  So  great  has  been  the 
need  for  additional  policy  and  guidance  in  this  area  that,  in  the  absence 
of  an  Army  Regulation,  DARCOM  proceeded  to  publish  DARCOM  Regulation  70-16: 
Management  of  Computer  Resources  in  Battlefield  Automated  Systems.  This 
DARCOM  regulation  provides,  among  other  things  for  the  documentation  of  PDSS 
requirements,  plans,  and  resource  estimates  early  in  the  acquisition  phase. 

With  respect  to  improving  Army  regulations  which  address  this  area,  the  new 
AR  18-1  does  place  increased  emphasis  on  the  Deployment  and  Operation  Phase 
of  the  system  life  cycle.  However,  changes  are  also  needed  in  ARs  70-1  and 
1000-1  to  provide  for  appropriate  attention  to  PDSS  and  to  preclude  the  type 
of  difficulties  experienced  by  users  as  a  result  of  system  deficiencies  and 
inadequate  support  planning  to  accomplish  corrective  actions  and  needed 
system  improvements.  Review  of  a  new  draft  chapter  to  be  incorporated  in  o 
revised  AR  70-1  indicates  this  problem  is  being  addressed  and  that  adequate 
guidance  will  exist  after  publication  of  the  new  AR  70-1.  Following  revision 
to  ARs  1000-1  and  70-1,  DA  Pamphlet  11-25  will  need  to  be  revised  to 
correspond  with  the  revised  regulatory  provisions. 

2-4.  FUNCTIONAL  AREA  ANALYSIS. 

a.  General .  This  paragraph  contains  a  discussion  and  analysis  of  the 
current  BFA-level  PDSS  system.  The  BFA  and  organizational  elements  identified 
in  Paragraph  2-2. a. (2)  are  addressed,  along  with  the  BAS  supported  within 
each  BFA.  Also  discussed  are  organizational  responsibilities,  operating 
procedures,  and  gaps  or  duplications  in  present  methods  of  planning  for  and 
providing  PDSS. 

b.  Force  Level  Control  Functional  Area. 

(1)  BAS  adddressed  within  this  functional  area.  The  Force  Level 
and  Maneuver  Control  System  (SIGMA)  and  the  Position  Location  Reporting  System 
(PLRS)  are  the  only  BAS  within  this  functional  area  at  the  present  time. 

Although  PLRS  is  a  command  and  control  support  system,  it  is  discussed  primarily 
in  Paragraph  2-4. h.  under  the  Communications  Functional  Area  since  the  US  Army 
Signal  Center  is  the  combat  development  proponent  for  the  system  and  it  is  in 
that  area  that  the  requirement  for  PDSS  resources  associated  with  the  system  2 
will  be  the  greatest.  Under  the  command,  control,  and  subordinate  systems  (CCS^) 
concept,  SIGMA  is  intended  to  satisfy  the  Army's  requirements  for  force  level 
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control  and  maneuver  control  in  the  1980s.  This  system  is  in  the  conceptual 
phase  of  development.  CACDA  has  prepared  a  Mission  Element  Needs  Statement 
(MENS)  (9  July  1980)  and  a  Letter  of  Agreement  (LOA)  is  being  prepared. 

Current  plans  provide  that  further  development  of  this  system  will  follow 
the  special  evolutionary  acquisition  process  described  in  Paragraph  13,  DODI 
5000.2,  19  March  1980.  This  DOD  instruction  authorizes  special  management 
procedures  in  the  acquisition  of  large  command  and  control  systems  that  are 
to  be  acquired  in  small  numbers.  In  accordance  with  this  flexible,  evolution¬ 
ary  development  concept,  a  limited  capability  developmental  system  is  being 
configured  for  fielding  and  testing  in  USAREUR  begining  in  October  1980. 

(2)  Organizational  elements  involved  in  planning  for  and  providing 
PDSS.  Three  military  organizations  and  one  contractor  are  primarily  involved 
in  planning  for  the  provision  of  PDSS  to  this  system  at  present.  These  are: 

•  The  Combined  Arms  Combat  Development  Activity  (CACDA),  the  Combat 
Developer  (CD)  proponent  for  this  system 

•  The  Communication's  Research  and  Development  Command  (CORADCOM), 
the  system  Materiel  Developer  (MD) 

•  USAREUR  and  subordinate  elements,  the  User  organizations  of  the 
initial  prototype  system 

•  The  current  contractor  --  Singer-Librascope 

Current  plans  provide  that  during  the  initial  evolutionary  development  and 
support  effort,  representatives  of  the  CD,  MD,  and  contractor  will  all 
operate  on-site  in  Europe.  These  representatives  will  provide  training  and 
logistical  and  technical  support  and  collect  operational  data  on  which 
further  system  development  may  be  based.  Plans  also  provide  for  the 
establishment  of  a  major  Software  Support  Center  at  Fort  Leavenworth  managed 
by  CORADCOM,  for  the  continued  development  and  post-deployment  support  of 
the  SIGMA  system. 

(3)  Responsibility/charters.  As  stated  above,  CACDA  is  assigned 
responsibility  as  the  CD  proponent  for  SIGMA.  Within  CACDA  at  present,  the 
Chief,  Army  C2/JINTACCS  Division,  C3I  Directorate,  is  assigned  this  respon¬ 
sibility.  The  C2  Development  Branch  performs  functions  to  fulfill  this 
responsibility  to  include  serving  as  CD  point  of  contact  with  the  system 
developer,  CORADCOM.  CD  responsibilities  with  respect  to  PDSS  for  SIGMA 
(both  the  initial  developmental  system  and  subsequent  versions)  include 
those  shown  in  Figure  2-5.  During  the  initial  fielding  and  testing  of  the 
developmental  system  in  USAREUR  over  the  next  year,  the  on-site  representa¬ 
tives  of  CACDA  will  be  involved  in  evaluating  the  operational  effectiveness 
of  the  initial  system  and  collecting  data  for  use  in  formulating  and  re¬ 
fining  User  operational  requirements. 

(4)  Regulatory/directive  authorities.  The  principal  regulatory 
authorities  from  which  the  CD  responsibilities  listed  above  are  derived  are 
those  cited  in  Paragraph  2-2. b. ,  particularly: 

•  DODI  5000.2 

•  AR  10-41 

•  AR  70-1 

•  AR  71-3 

•  AR  1000-1 

•  TRADOC  REGULATION  10-41 


1.  Specifying  functional  system  change  requirements 
including  interoperability  requirements  to  the  MD 

2.  Participation  on  the  Computer  Resources  Working  Group 
(CRWG)  and  Configuration  Control  Board  (CCB) 

3.  Monitoring  Development  Testing  (DT) 

4.  Representing  the  user  as  appropriate 

5.  Participating  in  or  planning  and  conducting  (as  directed) 
Operational  Testing  of  system  changes 

6.  Planning  and  monitoring  or  conducting  User 
Acceptance  Testing 

7.  Addressing  user-reported  system  problems 

8.  Analyzing  proposed  system  changes 

9.  Prioritizing  approved  system  changes  and  in  coordination 
with  the  MD,  establishing  target  completion  dates 

10.  Analyze  training  development  requirements  resulting 
from  system  changes 

11.  Initiating  action  to  address  training  requirements 
concurrently  with  system  development  or  changes 

12.  Coordinating  with  the  MD,  the  release  of  system 
change  packages  to  the  field 

13.  Performing  periodic  reevaluation  of  system  suitability 


Figure  2-5.  Basic  CD  PDSS  responsibilities 
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•  TRADOC  REGULATION  71-12 

•  DA  PAMPHLET  11-25 

•  CAC  AND  FORT  LEAVENWORTH  REGULATION  10-1 


(5)  Operating  procedures.  At  present,  CD  efforts  associated  with 
PDSS  for  SIGMA  are  limited  to  the  coordinated  MD-CD  planning  described  above, 
and  initial  implementation  actions. 

(6)  Gaps  and  duplications.  There  are  no  apparent  gaps  or 
duplicative  efforts  in  the  actions  related  to  SIGMA  at  this  time.  At  this 
early  stage  in  the  Conceptual  Phase  of  the  system  development  effort,  CD 
emphasis  is  on  specifying  system  functional  requirements  and  coordinating 
actions  associated  with  fielding  the  initial  developmental  system.  In  this 
respect,  the  flexible  system  development  process  authorized  by  DODI  5000.2 
provides  for  the  system  to  evolve  over  a  period  of  time.  This  process  may 
necessitate  greater  attention  to  configuration  management  and  System  User 
documentation  and  may  also  impose  additional  training  requirements  as 
different  versions  of  the  system  evolve,  all  of  which  are  of  major  concern. 

c.  Fire  Support  BFA.  The  Fire  Support  BFA  is  the  major  contributor 
of  fire  support  for  maneuver  forces.  The  focal  point  for  activities  in  this 
BFA  is  the  Field  Artillery  Center  and  School  at  Fort  Sill,  Oklahoma. 

(1)  BAS  addressed  within  this  BFA.  The  Category  1  and  2  systems 
which  are  addressed  within  this  BFA  are  as  follows: 

(a)  Tactical  Fire  Direction  System  (TACFIRE) .  This  system 
is  already  partially  fielded  (IOC-1979),  and  therefore,  has  PDSS  activity 
taking  place.  The  proponent  is  USAFAS  and  the  developing  command  is  CORADCOM. 
Category  is  1. 


(b)  Battery  Computer  System  AN/GYK-29  (BCS).  This  system's 
life  cycle  status  is  DT  II.  When  ready  for  deployment  (IOC-1982),  the  BCS 
will  replace  the  Battery  Display  Unit  in  TACFIRE  (1982),  be  used  in  the  MLRS 
launcher,  and  be  used  with  the  LANCE  missile.  The  proponent  is  USAFAS  and 
the  developing  command  is  CORADCOM.  Category  is  2A. 

(c)  Pershing  II  Tactical  Missile  System  (PII).  This  system's 
life  cycle  status  is  DT/OT  I  with  an  expected  fielding  date  of  1983.  Although 
this  system  contains  primarily  embedded  firmware,  it  may  still  require  PDSS 
activity.  The  proponent  for  PII  is  USAFAS  and  the  developing  command  is  MICOM. 
Category  is  2B. 


(d)  Field  Artillery  Digital  Automatic  Computer  (FADAC).  This 
system  is  currently  being  phased  out  and  will  be  replaced  by  the  BCS.  There¬ 
fore,  it  will  have  no  PDSS  activity  associated  with  it  and  will  not  be 
considered  further  in  this  study.  Category  is  2A. 


i 
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(2)  Organizational  elements  involved  in  planning  for  and  providing 
PDSS.  For  the  BAS  listed  above,  there  are  currently  nine  major  organizational 
elements  (with  various  subelements)  which  are  involved  in  planning  for  and 
providing  PDSS.  These  organizational  elements  are  listed  below  and  their 
PDSS  functions  are  described  in  Paragraphs  2-4. c(3)  through  2-4. c(6). 

•  TRADOC  System  Manager  (TSM)  for  Field  Artillery  Tactical  Data 
Systems  (FATDS) 

•  Tactical  Data  Systems  Division  (TDS),  Combat  Developments 
Directorate  (CD),  USAFAS 

•  The  TRADOC  System  Manager  (TSM)  for  the  Multiple  Launch 
Rocket  System  (MLRS)  Fire  Direction  System  (FDS) 

•  The  Software  Validation  Branch,  Computer  Test  and  Technical 
Support  Division,  US  Army  Field  Artillery  Board  (USAFABD) 

•  The  TRADOC  System  Manager  (TSM)  for  Pershing  II  Tactical  Missile 
System  (PI I) 

•  The  local  Software  Configuration  Control  Board  (SCCB) 

e  The  Field  Artillery  Interoperability  Configuration  Control  Board 
(FAICCB) 

•  The  Systems  Configuration  Control  Board 

•  The  DARCOM  TACFIRE  Software  Support  Group  (TSSG)  at  Fort  Sill. 

(3)  Responsi bi 1 i ti es/charters . 

(a)  The  mission,  authority,  and  responsibilities  of  the 
TSM-FATDS  are  spelled  out  in  the  TRADOC  System  Manager  Charter,  Field 
Artillery  Tactical  Data  Systems  (FATDS),  dated  1  November  79.  By  this 
charter,  his  mission  is  to  "conduct  total  system  management  within  TRADOC 
for  FATDS  to  include  TACFIRE,  Battery  Computer  System  (BCS),  Digital  Message 
Device  (DMD),  and  other  follow-on  system  enhancements."  One  of  the 
responsibilities  of  the  TSM-FATDS  which  is  delineated  in  that  charter  is 
"Managing  the  TRADOC  aspects  of  Post- Deployment  Software  Support  (PDSS) 

for  FATDS  and  other  Field  Artillery  systems  requiring  software  support." 
Included  in  these  PDSS  duties  is  coordination  with  other  organizations  to 
ensure  that  plans  for  training,  personnel,  logistics,  testing,  and  new 
doctrine/ tactics  are  timely  and  fully  integrated  into  the  materiel 
development  program. 

(b)  The  Tactical  Data  Systems  Division  (TDS),  Combat 
Developments  Directorate  (CD),  USAFAS  has  maintenance  and  support  respon¬ 
sibilities  for  all  FA  systems  which  have  reached  IOC.  Included  in  these 
responsibilities  is  the  front-end  development,  definition,  and  design  of 
system  changes  to  meet  User  needs  before  release  to  the  Materiel  Developer. 

The  TDS-CD  also  analyzes  and  develops  requirements  for  training  devices 
and  procedures  for  fielded  BAS  as  software  changes  occur. 
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(c)  The  TRADOC  System  Manager  (TSM)  for  the  Multiple  Launch 
Rocket  System  (MLRS)  Fire  Director  System  (FDS)  monitors  overall  management 
of  the  MLRS-FDS  during  production  and  deployment  phases.  He  acts  as  user 
representative  in  the  writing  of  the  Computer  Resources  Management  Plan 
(CRMP)  for  MLRS-FDS.  He  ensures  User  participation  in  all  ECP's.  In  addi¬ 
tion,  the  TSM-MLRS  participates  as  a  principal  member  on  the  TACFIRE/MLRS 
Executive  Committee  dealing  with  all  aspects  of  TACFIRE-FDS  interoperability. 

(d)  The  Field  Artillery  Board  at  Fort  Sill  is  one  of  eight 
US  Army  test  boards  and  as  such  is  assigned  the  following  missions  under 
TRADOC  Regulation  10-41: 

•  Plan,  conduct,  and  report  on  operational  and  other  User  tests 

t  Participate  in  other  testing  as  directed 

•  Provide  advice  and  guidance  on  test  matters  to  Combat,  Training, 
and  Materiel  Developers,  other  services  and  private  industry 

t  Conduct  other  tests  and  selected  specific  evaluations  as  directed 
by  CG  TRADOC. 

On  10  August  1977,  the  USAFABD  was  designated  by  HQ  TRADOC  (via  TRADOC  Msg, 
ATCD-TM,  101918Z  Aug  77,  subject:  TACFIRE  Tape  Validation)  as  the  responsible 
agency  for  User  validation  of  TACFIRE  system  master  tapes  developed  by  the 
DARCOM  TACFIRE  Software  Support  Center,  Fort  Sill  (TSSG).  In  accordance  with 
this  tasking,  the  Software  Validation  Branch,  Test  and  Technical  Support 
Division,  USAFABD,  has  been  performing  acceptance  testing  of  new  TACFIRE 
software  releases.  Depending  on  requirements,  this  testing  has  been  or  can 
be  0T,  DT,  or  command  post  exercise  oriented.  In  addition  to  its  testing 
responsibilities,  this  organization  is  also  a  member  of  the  local  Software 
Configuration  Control  Board. 

(4)  Regulatory/di recti ve  authorities.  Listed  below  are  the  re¬ 
gulations  and  other  documents  which  prescribe  the  responsibilities  for  and 
govern  or  impact  upon  PDSS  functions  in  the  Field  Artillery  BFA. 

•  AR  10-5:  Organizations  and  Functions  of  the  US  Army,  1  November  78 

•  AR  10-41 :  Organization  and  Functions,  United  States  Army  Training 
and  Doctrine  Command,  27  June  1973 

•  TRADOC  Regulation  10-41:  Organization  and  Functions,  1  May  1980. 

•  USAFACFS  Regulation  10-1:  Manual  of  Organization  and  Functions 

•  Pamphlet  11-25:  Life  Cycle  System  Management  Model  for  Army 
Systems,  21  May  1975 

•  Department  of  Defense  Directive  5000.1:  Major  System  Acquisitions, 
18  January  1977 

t  Department  of  Defense  Directive  5000.2:  Major  System  Acquisition 
Procedures,  19  March  1980 

t  Department  of  Defense  Directive  5000.3:  Test  and  Evaluation, 

26  December  1979 

•  Post-Deployment  Management  Plan  for  Fire  Direction  System, 

Artillery  AN/GSG-10(v)  (TACFlRE) .  Draft: 
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(5)  Relationship  with  Users,  Materiel  Developers,  Training 
Developers.  ~ 

(a)  Within  the  Field  Artillery  BFA  community,  one  of  the 
approved  documents  which  addresses  day-to-day  working  relationships  among  Users, 
Materiel  Developers,  and  Training  Developers  is  the  TSM-FATDS  Charter.  This 
charter  specifies  that  the  TSM-FATDS  is  authorized  to  coordinate  directly 
with  the  following  organizations  on  matters  relating  to  FATDS: 

•  HQDA 

•  HQ  TRADOC 

•  USADARCOM,  PM  and  Major  Subordinate  Commands 

e  USAOTEA 

•  USAMACOM  (USAFORSCOM,  USAREUR,  Eighth  US  Army) 

•  CDR  MILPERCEN 

•  Other  agencies  and  services  as  required. 

Operating  under  these  guidelines,  the  following  working  relationships  have 
been  established: 


1_.  TSM-FATDS  interacts  bi-weekly  with  HQDA  on  fielding, 
scheduling,  program  status,  and  program  decisions. 

2.  TSM-FATDS  interacts  with  HQ  TRADOC  monthly  on 

training  support. 

3_.  TSM-FATDS  interacts  weekly  with  CERCOM  PM  on  NETT 

coordination. 

4.  TSM-FATDS  interacts  daily  with  CORADCOM  PM-FATDS 
on  system  requirements. 

5_.  TSM-FATDS  interacts  weekly  with  USAFABD  on  software 
acceptance  testing,  system  problem  areas,  and  recommended  changes. 

£.  USAFAS-CD-TDS  interacts  daily  with  PM-FATDS  on 
system  requirements,  interoperability,  data  base.  Basis  of  Issue  Plans  (BOIP), 
Qualitative  and  Quantitative  Personnel  Requirements  Information  (QQPRI),  and 
maintenance  support. 


USAFAS-CD-TDS  interacts  daily  with  TRADOC  FA  Branch 
on  the  same  topics  as  6.  above. 

8.  USAFAS-CD-TDS  interacts  weekly  with  USAFABD  on 
acceptance  testing  of  software. 

(b)  A  second  document  which  addresses  day-to-day  working 
relationships  for  the  Field  Artillery  BFA  is  a  TRADOC  Msg,  ATCD-TM,  101918Z 
Aug  77,  subject:  TACFIRE  Tape  Validation.  Based  on  this  message,  the 
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USAFABD  developed  a  concept  for  TACFIRE  software  validation  in  coordination 
with  the  US  Army  Field  Artillery  School  (USAFAS),  DARCOM  TACFIRE  Software 
Support  Group  (TSSG),  and  Program  Manager,  Operational  Tactical  Data  Systems 
(PM-OPTADS). 


relationships: 


From  this  concept  has  evolved  the  following  working 


USAFABD  interacts  daily  with  TSSG  on  testing,  system 
problem  areas,  and  technical  questions  on  software  functions. 

2.  USAFABD  interacts  weekly  with  PM-FATDS  on  system 

problem  areas 

3_.  USAFABD  interacts  weekly  with  HQ  TRADOC  on  testing 
coordination  and  approval. 

(c)  In  addition  to  the  working  relationships  described  above, 
several  informal  working  groups  have  been  established  as  described  below: 

1_.  A  local  Software  Configuration  Control  Board  (SCCB) 
has  been  formed  to  review  software  problems.  The  group  currently  reviews  all 
TACFIRE  software  problems  and  adds  those  which  it  approves  to  a  prioritized 
list  for  subsequent  correction.  The  SCCB  is  chaired  by  the  Chief,  TSSG  and 
has  as  voting  members  the  TSM-FATDS  and  USAFAS-TDS-CD. 

2.  A  Field  Artillery  Interoperability  Configuration 
Control  Board  (FAICCB)  has  been  formed  to  monitor  and  maintain  interoperability 
between  all  Field  Artillery  systems  and  subsystems.  The  FAICCB  is  chaired 
by  TSM-FATDS. 


2-  A  System  Configuration  Control  Board  has  been  formed 
to  handle  Army-NATO  and  Army-Other  Services  interoperability  problems. 
Chairman  is  PM-OPTADS. 

(6)  Operating  procedures.  Within  the  Field  Artillery  BFA,  the 
only  PDSS  operating  procedure  which  has  been  established  and  is  currently 
being  used  is  one  which  supports  TACFIRE.  Figure  2-6  (which  was  furnished 
by  USAFAS-CD-TDS)  depicts  in  general  terms  the  operating  procedure  which  is 
currently  being  used  to  implement  software  changes  in  the  TACFIRE  system. 

In  this  procedure,  requests  for  system  changes  may  be  initiated  as  the  result 
of  problem  reports  from  the  field,  improvement  requests  from  the  User, 
policy  and/or  procedural  changes,  or  the  introduction  of  a  new  Configuration 
End  Item  (CEI).  These  change  requests  are  channeled  to  the  PM-FATDS  who 
determines  if  the  request  involves  a  hardware  change  or  a  software  change. 

If  a  software  change  is  involved,  the  request  is  passed  on  to 
the  Software  Configuration  Control  Board  which  then  makes  the  determination 
as  to  whether  the  requested  change  will  or  will  not  be  made.  If  the  SCCB 
decides  that  the  change  will  be  made,  TSM-FATDS  assigns  a  priority  to  it  and 
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SOFTWARE  CHANGE  PROCESS 


Figure  2-6.  TACFIRE  software  change  process 
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adds  it  to  a  prioritized  list  of  other  TACFIRE  software  changes.  This 
prioritized  list  is  then  passed  on  to  the  Software  Support  Facility  (currently 
represented  by  USAFAS-CO-TDS)  who  perform  the  evaluation  and  definition,  and 
establish  requirements  for  the  software  changes  which  they  then  release  to 
the  Materiel  Developer  (TSSG). 

The  TSSG  performs  the  development  of  the  software  modifications. 
The  resulting  code  is  then  validated  and  verified  for  correctness  by  TSSG 
under  the  guidance  and  observation  of  USAFABD.  An  independent  validation  is 
then  performed  by  USAFABD  to  evaluate  the  modified  system's  operational 
capabilities.  Once  the  software  changes  have  passed  acceptance  testing,  they 
are  added  to  a  master  system  update  tape  along  with  other  approved  software 
modifications.  At  the  appropriate  time,  which  must  be  coordinated  with  the 
hardware  deployment  schedule,  copies  of  the  master  tape  are  issued  to  all 
locations  where  TACFIRE  is  deployed.  After  this  update  tape  has  been 
distributed,  any  subsequent  software  changes  will  be  added  to  a  new  master 
tape  as  the  process  continues. 

An  issue  of  some  concern  at  Fort  Sill  has  arisen  in  connection 
with  such  testing.  This  issue  involves  who  should  perform  operational  type 
testing,  particularly  where  the  software  changes  are  relatively  minor  and 
are  not  anticipated  to  significantly  change  system  characteristics.  This 
issue  stems  from  varying  interpretations  of  DODD  5000.3,  Test  and  Evaluation, 
and  the  term  "operational  testing".  One  interpretation,  held  by  some  people 
at  OTEA  and  TRADOC  HQ,  would  call  for  OTII  and  OTEA  involvement  in  all  such 
cases.  Other  interpretations  are  that  it  is  not  the  fundamental  intent  of 
the  regulations  to  require  a  massive  and  expensive  process  to  be  imposed 
where  less  complex  methods  can  serve  the  purposes  satisfactorily. 

(7)  Chains,  gaps,  and  duplications  in  current  PDSS  process. 

Since  the  PDSS  process  which  is  supporting  TACFIRE  is  getting  the  job  done, 
one  might  say  there  are  no  gaps.  However,  a  closer  analysis  reveals  that 
several  gaps  have  been  bridged  temporarily  through  ingenuity  and  "gentlemen's 
agreements".  The  personnel  performing  PDSS  for  TACFIRE  have  identified  the 
following  gaps: 


(a)  There  is  a  need  for  a  regulatory  document  or  documents 
which  will  address  these  issues: 

•  The  establishment  of  a  direct  working  relationship  between  the 
DARCOM  software  support  group  and  the  TRADOC  software  support 
group, 

•  The  formal  establishment  of  various  configuration  control  boards 
such  as  SCCB  and  FAICCB, 

•  Provision  for  the  updating  of  training  documents  in  connection 
with  software  modifications,  and 

•  Procedures  for  the  funding  of  user  acceptance  testing. 

(b)  There  is  a  need  for  a  front-end  requirements  analysis 
and  simulation  facility. 
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(c)  There  is  a  need  for  an  instrumented  test  facility  to  provide 
for  scenario  generation  and  the  automation  of  test  results  analysis  in  support 
of  user  acceptance  testing.  This  should  be  a  DARCOM-TRADOC  shared  facility. 

d.  Air  Defense  BFA. 

(1)  BAS  addressed  within  this  BFA.  Battlefield  automated  systems 
which  are  anticipated  to  have  a  significant  impact  on  PDSS  resource  requirements 
within  the  Air  Defense  BFA  are  identified  below. 


(a)  PATRIOT  air  defense  missile  system.  The  PATRIOT  system  and 
its  realtime  interfaces  with  other  automated  systems  present  a  very  substantial 
PDSS  requirement.  Just  past  the  limited  production  decision  point,  PATRIOT  is 
heavily  automated  (embedding  in  its  software  a  broad  range  of  functions  including 
firing  doctrine  and  scheduling  of  system  resources),  highly  mobile,  and  must 
interoperate  in  an  integrated  air  defense  environment  with  other  systems,  services 
and  nations.  In  this  environment,  realtime  may  be  measured  in  microseconds. 

Although  human  override  provisions  are  included,  the  system  normally  performs  all 
target  acquisition,  identification,  tracking,  engagement  decision  and  weapon 
assignment,  missile  control,  and  post-intercept  kill  assessment  functions  automatic¬ 
ally,  in  coordination  with  other  AD  weapons  (ground  and  air)  and  control  systems. 

In  addition  to  the  software  required  to  perform  these  tactical  functions,  additional 
system  software  supports  personnel  in  maintenance  operations  and  troop  proficiency 
training.  PATRIOT  is  designed  to  operate  as  part  of  an  integrated  air  defense 
structure,  under  centralized  or  decentralized  modes  of  control.  The  PATRIOT  fire 
unit  is  designed  to  operate  in  centralized,  decentralized,  independent  and 
autonomous  modes  vis-a-vis  the  PATRIOT  CCS  (battalion  level  command  and  control 
system).  PATRIOT  is  designated  as  the  US  replacement  for  NIKE  Hercules  and,  to 
some  degree  Improved  HAWK.  PATRIOT  software  includes  a  vast  number  of  instructions, 
although  it  can  be  seen  from  the  table  below  that  the  bulk  of  this  lies  in  support 
software  areas,  and  that  more  than  half  of  the  software  in  the  field  units  of  the 
weapon  system  itself  are  diagnostic  in  function. 


Fire  Unit  (ECS) 


Approximate  Words  (24-bit)  of  Instruction/ 
Data  in  Core  Memory 

Operations  Programs  Maint  &  Diagnostics 


Tactical  Software 

254 

K 

Initial ization 

260 

K 

Diagnostics  (ECS) 

93 

K 

Diagnostics  (Radar) 

519 

K 

MEP  (Maintenance) 

200 

K 

Radar  Resident  Software 

37 

K 

Support  Software  - 

■  700  K 

TOTAL  . 

— 

... 

Battalion  (CCS) 

193 

K 

UNK 

Other  Software  - 

-3000  K 

TOTAL,  PATRIOT  SOFTWARE 


-  5200  K 
(Approx. ) 


The  Product  Improved  Vulcan  (PIVADS)  and  the  Chaparral  PIP  are  not 
deemed  to  be  of  significant  impact  and  are  not  included. 
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(b)  AN/TSQ-73,  Missile  Minder.  The  AN/TSQ-73  Missile  Minder 
is  a  real  time,  air  defense  battle  management/fire  distribution  system  which 
provides  group  and  battalion  level  command  and  control  for  currently  fielded 
medium  and  high  altitude  surface-to-air  missile  fire  units  (I-HAWK  and  NIKE 
HERCULES).  The  functions  of  the  AN/TSQ-73  are  similar  to  those  performed 
within  the  control  portions  of  the  PATRIOT  System,  with  the  exception  that  the 
AN/TSQ-73  also  provides  group  level  command  and  control  (of  I-HAWK,  HERCULES 
and  PATRIOT  battalions).  The  Missile  Minder  is  in  the  post-deployment  stage 
(was  fielded  in  1979).  Major  enhancements  are  required  but  are  delayed 
because  of  constrained  core  (PIP  to  upgrade  memory  expected  to  be  funded  in 
1983)  and  no  USAADS  personnel  resources  to  define  requirements. 

2 

(c)  SHORAD  C  .  The  Short  Range  Air  Defense  Command  and  Control 
system  provides  more  positive  and  faster  control  of  the  short  range  air  defense 
weapons  systems  such  as  Redeye/Stinger,  Chaparral,  Vulcan,  ROLAND,  and  DIVAD 
Gun.  Such  control  is  now  accomplished  entirely  manually.  SHORAD  C^  is  in  early 
concept  formulation  stages.  It  will  probably  lean  heavily  on  other  systems  such 
as  the  PLRS/JTIDS  Hybrid  (see  Paragraph  2-4. h.,  for  the  Commmuni cations  BFA)  and 
will  bear  some  resemblance  to  AN/TSQ-73.  The  SHORAD  Cd  concept  envisions 
automated  command  and  control  systems  at  platoon,  battery,  and  battalion  level, 
with  interfaces  at  the  battalion  level  to  other  automated  C^  systems. 

(d)  DIVAD  Gun.  The  Division  Air  Defense  (DIVAD)  Gun  system 
is  in  the  Engineering  Development  Stage  and  is  intended  to  either  replace  or 
update  and  substantially  expand  upon  the  capabilities  of  the  Vulcan  gun  system 
which  has  been  in  the  field  for  many  years  as  an  interim  short  range  AD  gun 
system.  Because  of  time  constraints  during  the  DIVAD  Gun  conceptual  design 
effort,  design  was  based  upon  user  developed  ROC  and  RFP,  neither  of  which 
contained  tactical  software,  interoperability  or  command  and  control  require¬ 
ments.  Consequently,  user  requirements  for  software  and  command  and  control, 
developed  subsequent  to  prototype  development,  have  not  been  incorporated  into 
the  DIVAD  Gun  system.  These  requirements  may  be  "cut  in"  to  the  production 
system  during  the  maturity  phase  of  system  development  (after  contractor 
selection)  or  added  later,  as  enhancements/product  improvements.  This  BAS  con¬ 
tains  a  substantial  amount  of  software,  estimated  to  be  in  excess  of  100K  of 
code.  However,  the  majority  of  this  software  is  expected  to  be  relatively  stable 
after  system  development,  with  only  that  portion  embedding  tactics,  doctrine, 
interoperability  and  command  and  control  being  highly  dynamic  because  of  the 
earlier  neglect  of  these  areas  and  because  of  the  evolutionary  nature  of  the 
interdependent  SHORAD  Cc  concept.  Over  600  systems  are  to  be  fielded.  Since 
Combat  Developer  involvement  has  been  limited,  many  problems  may  remain  to  be 
worked  out  in  final  stages  of  development  or  even  after  fielding. 

(e)  I-HAWK.  The  Improved  HAWK  air  defense  missile  system 
fielded  in  1972,  involves  an  application  of  1960's  computer  technology  to 
rudimentary  and  rather  inflexible  automation  of  some  of  the  air  defense 
engagement  functions  which  were  handled  manually  in  the  original  medium  range 
HAWK  system,  which  has  been  in  the  field  since  the  early  1 960 ’ s .  Attention  is 
now  being  given  to  additional  improvements,  including  increased  survivability, 
memory,  and  interoperability,  plus  a  hybrid  version  for  co-deployment  with 
PATRIOT.  Recent  I-Hawk  modifications  have  included  the  development  of  software 


which  effects  a  fully  automated  interface,  using  ATDL-1 ,  between  the  I-Hawk 
fire  units  and  the  AN/TSQ-73  command  and  control  system.  This  data  link 
provides  for  the  full  uplink  and  downlink  of  target  information  between 
these  systems,  in  addition  to  the  command  and  control  information  provided 
by  the  earlier  data  link  and  software.  The  multi-service  and  international 
employment  of  Hawk,  coupled  with  its  world-wide  deployment,  have  resulted 
in  a  software  change  process  which  includes  NATO  and  USMC  representatives 
in  all  software  decisions.  An  unfortunate  aspect  of  I-HAWK  software  support 
is  that  a  formal  procedure  for  PDSS  has  never  been  developed  for  this 
system,  despite  its  over  eight  years  of  tactical  employment  and  the  numerous 
software  changes  made  and  planned. 

(f)  ROLAND.  The  ROLAND  air  defense  missile  system  was  chosen 
to  replace  the  Chaparral  missile  primarily  in  a  way  that  would  minimize  lead- 
time  and  cost,  by  making  use  of  an  existing  French  and  German  development 
effort.  Therefore,  the  US  Combat  Development  community  has  had  almost  no 
influence  over  the  system,  although  it  has  been  adapted  to  production  in  the 
US.  While  the  system  involves  a  moderate  degree  of  automation  (possibly  in 
excess  of  70K  lines  of  code),  ROLAND  software  is  essentially  a  digital 
emulation  of  earlier  analog  fire  control  logic  because  of  the  limited  involve¬ 
ment  of  the  combat  developer  in  the  US  development  of  this  system.  Incorpora¬ 
tion  of  tactical  doctrine,  interfacing  with  the  SHORAD  C^  system  and  other 
aspects  of  interoperability  effected  through  the  systems'  software  are 
anticipated  to  present  some  very  troublesome  problems  because  of  current 
hardware  design  which  does  not  allow  for  desired  software  enhancements  and 
growth.  The  system  is  now  in  advanced  engineering  development,  and  solution 
of  software  and  interoperability  problems  may  require  a  significant  PDSS 
effort. 


(g)  Air  Defense  Electronic  Warfare  System  (ADEWS).  ADEWS  is 
in  the  Conceptual  Study  Phase  of  the  life  cycle.  It  will  involve  a  relatively 
large  amount  of  software.  Therefore,  it  is  listed  here  because  of  a  potenti¬ 
ally  significant  impact  on  PDSS  requirements  at  some  time  in  the  future. 

(h)  Other  Systems.  Other  complex,  sophisticated,  software 
driven/automated  air  defense  systems  are  in  various  stages  of  development  and 
expected  to  be  fielded  by  the  mid-1980s.  These  systems,  which  cannot  be 
described  further  because  of  security  reasons,  will  interface  with  other 
members  of  the  air  defense  family  and  will  require  moderate  to  substantial 
changes  in  the  software  of  today's  fielded  and  developmental  systems. 

(2)  Organizational  elements  involved  in  planning  for  and  providing 
PDSS.  In  the  Air  Defense  BFA,  organizational  elements  involved  in  planning 
for  and  providing  PDSS  can  be  divided  into  two  general  categories:  elements 
involved  explicitly  or  implicitly  in  all  air  defense  systems  and  elements 
directly  involved  with  specific,  individual  systems. 

(a)  Elements  for  all  AD  systems.  For  all  AD  systems,  organ¬ 
izational  elements  involved  in  planning  for  or  providing  PDSS  essentially 
consist  of  DARCOM  (the  materiel  developer),  TRADOC  (the  combat  developer)  and 
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Users.  Within  DARCOM  principal  elements  involved  (in  addition  to  the  project 
managers  who  will  be  addressed  by  system  below)  are  HQ  DARCOM,  CORADCOM, 
ARRADCOM,  and  MICOM.  Within  TRADOC,  principal  elements  involved  are  HQ 
TRADOC,  CAC,  and  the  AD  Center  and  School.  (TRASANA  is  also  involved  to  a 
limited  extent,  with  increased  participation  currently  being  explored.) 

Within  the  AD  Center  and  School,  in  addition  to  the  Commander/Commandant 
and  Assistant  Commandant  (and  in  addition  to  the  TRADOC  System  Managers  for 
PATRIOT,  DIVAD  Gun  and  ROLAND)  two  elements  are  specifically  involved  -  the 
Directorate  of  Combat  Developments,  and  the  Directorate  of  Training  Develop¬ 
ments.  Within  the  Directorate  of  Combat  Developments,  the  Combat  Systems 
Software  Division  is  the  principal  element  involved  in  software  development 
and  in  planning  for  and  providing  PDSS.  Within  the  Directorate  of  Training 
Developments,  the  principal  element  involved  is  the  Software  Branch,  PATRIOT/ 
Hercules  Division,  Instructional  Systems  Development  Department  (emphasis  on 
instructional  and  exportable  training  simulators  and  devices  and  training 
scenarios).  The  Army  Research  Institute  Field  Office,  Air  Defense  and  the 
PATRIOT  Software  Support  Office,  both  located  a  Fort  Bliss,  also  provide 
assistance  in  the  software  development  and  PDSS  efforts.  Among  users, 
principal  elements  are  FORSCOM,  USAREUR,  the  32d  AADCOM  (Europe)  and  the 
USMC,  USAF  and  NATO. 

(b)  AN/TSQ-73,  Missile  Minder  .  Principal  organizational 
elements  involved  in  planning  for  or  providing  PDSS  for  the  AN/TSQ-73  are: 

•  A  part  of  the  Combat  Systems  Software  Division,  DCD,  USAADS 

•  Elements  of  the  Directorate  of  Training  Development,  the  Director¬ 
ate  of  Training  and  Doctrine,  and  the  Air  Defense  Board 

•  The  Software  Support  Division  (Bldg  1044,  Fort  Bliss),  Project 
Manager,  Air  Defense  Command  and  Control  Systems  (Redstone  Arsenal). 
(Note:  This  Division  was  attached  to  CORADCOM  in  August  1980  but 

is  to  transfer  to  MICOM  control  on  1  October  1980.  Also,  this 
Division  is  currently  supported  by  three  contractors;  Litton  Data 
Systems  Division,  Intercon  Systems  Corp,  and  Command,  Control  and 
Communications  Corp  (4C's). 

§  Project  Manager,  Air  Defense  Command  and  Control  Systems  (Redstone 
Arsenal).  USAMICOM 

9  Missile  Software  Support  Center  (Redstone  Arsenal),  MICOM 

•  32d  AADCOM,  Europe 

t  11th  ADA  Brigade  (Fort  Bliss),  and  other  FORSCOM. 

AN/TSQ-73  software  is  developed  and  maintained  in  accordance  with  TACS/TADS 
and  ATDL  standards.  Interface  with  NATO  systems  is  provided  through  a  fully 
automated  buffer  (ABLE)  maintained  by  the  Software  Support  Division,  Fort  Bliss. 

(c)  PATRIOT.  Principal  organizational  elements  involved  in 
planning  for  or  providing  PDSS  for  the  PATRIOT  system  are: 

•  A  part  of  the  Combat  Systems  Software  Division,  DCD,  USAADS.  This 
Division  also  makes  use  of  the  TRADOC  Data  Processing  Field  Office 
(Fort  Leavenworth)  computers  via  secure  terminal  at  Fort  Bliss,  and 
receives  contractor  support  in  development/maintenance  of  PATRIOT 
simulators  (SAI). 

•  A  part  of  the  Directorate  of  Training  Development,  USAADS 

•  PATRIOT  Software  Support  Office  (Fort  Bliss),  Project  Manager,  PARTIOT 
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•  TRADOC  System  Manager  -  PATRIOT  (Fort  Bliss) 

•  Project  Manager,  PATRIOT  (Huntsville),  DARCOM 

•  PM  PATRIOT/ DARCOM  Field  Office,  White  Sands  Missile  Range  (Launch 
Complex  38) 

•  Raytheon  Company,  PATRIOT  Software  Support  Organization,  Bedford, 
Mass^ 

•  Raytheon  System  Test  Facility,  White  Sands  Missile  Range  (Launch 
Complex  38) 

•  Sanders  Associates,  Nashua,  N.H.  (Training  Device) 

•  Verification  and  Validation  (V&V)  Organization,  Army  Missile 
Systems  Software  Center  (MSSC)  (Redstone  Arsenal),  MICOM  (supported 
by  an  independent  contractor) 

•  PATRIOT  Configuration  Control  Board,  PATRIOT  Project  Office 
(Redstone  Arsenal ) 

•  PATRIOT  Software  Review  Board,  PATRIOT  Project  Office  (Redstone 
Arsenal ) 

t  Joint  Interface  Test  Force  (JITF),  Hanscom  Field,  Mass 

•  Project  Manager,  Air  Defense  Comnand  and  Control,  Huntsville,  Alabama 

•  AN/TSQ-73  Software  Support  Division,  Fort  Bliss 

•  32D  AADCOM  and  USAREUR 

(d)  Improved  Hawk  System.  Principal  organizational  elements 
involved  in  planning  for  or  providing  PDSS  for  the  Improved  Hawk  System  are: 

•  Project  Manager,  Improved  HAWK,  USAMICOM 

•  Ratheon  Company,  Tactical  Ground  Defense  Systems,  Bedford,  Mass 

•  USAMICOM  R  &  E  Labs 

•  Project  Manager,  AD  Command  and  Control  Systems,  Huntsville,  Alabama 

•  AN/TSQ-73  Software  Division,  DCD,  USAADS,  Fort  Bliss 

•  NATO  Hawk  Project  Management,  Paris,  France 

•  USMC  (MCDEC  and  MCTSSA) 

•  32D  AADCOM,  USAREUR 

•  DTD,  USAADS,  Fort  Bliss 

Note  -  In  spite  of  the  organizations  involved  in  I-Hawk  software  development 
and  change,  no  formal  PDSS  planning  exists  for  this  system  although  the 
software  is  in  rapid,  evolutionary  development  and  has  been  throughout  the 
the  eight  years  of  fielding. 

2 

(e)  Other  systems.  Because  the  SHORAD  C  system  is  in  early 
concept  formulation  stages,  no  DARCOM  project  manager  (PM)  or  TRADOC  System 
Manager  (TSM)  exists  for  this  system,  and  activity  is  essentially  confined  to 
the  Directorate  of  Combat  Development,  USAADS.  Potentially,  among  the 
organizational  elements  that  may  become  involved  with  SHORAD  C^  PDSS  are: 


2 

Includes  the  Tactical  Software  Development  Facility  (TDSF),  and  the 
Guidance  Test  and  Simulation  Facility  (GTSF). 


I 
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the  PM's  and  TSMs  of  the  short  range  air  defense  systems.  Stinger,  DIVAD  Gun, 
and  ROLAND,  the  TSM-PLRS/JTIDS  Hybrid,  at  Fort  Gordon,  the  Software  Support 
Division  (Fort  Bliss)  of  the  PM,  Air  Defense  Command  and  Control  Systems, 
as  well  as  that  PM  (Redstone  Arsenal).  With  respect  to  planning  for  and 
providing  PDSS  for  DIVAD  Gun,  the  PM  at  Picatinny  Arsenal  and  the  TSM  at 
Fort  Bliss  are  among  organizational  elements  likely  to  be  involved.  For 
ROLAND,  both  a  PM  (at  Redstone  Arsenal)  and  a  TSM  (at  Fort  Bliss)  exist 
and  would  be  similarly  involved.  For  ADEWS,  in  early  study,  it  is  not  now 
clear  what  elements  may  become  involved,  aside  from  DCD,  USAADS. 

(3)  Responsibilities/Charters.  Responsibilities  of  the  various 
organizational  elements  involved  in  planning  for  or  providing  PDSS  in  the 
Air  Defense  BFA  stem  basically  from  two  sources.  One  source  is  the  chain  of 
basic  regulatory  authorities,  ranging  from  the  fundamental  DOD  and  Army  Reg¬ 
ulations,  particularly  AR  1000-1,  the  AR  70-series,  and  the  AR  10-series, 
through  the  local  10-series  regulations.  The  other  basic  source  of  respon¬ 
sibilities  is  the  detailed  plans  which  exist  for  post-deployment  management 
of  the  AN/TSQ-73  Missile  Minder  and  post-deployment  software  support  of  the 
PATRIOT  air  defense  missile  systems.  In  addition,  each  DARCOM  Project 
Manager  and  each  TRADOC  System  Manager  has  a  charter  from  the  respective 
headquarters.  The  PATRIOT  Post- Deployment  Software  Support  Implementation 
Plan,  issued  in  June  1980  by  the  PATRIOT  Project  Manager,  Redstone  Arsenal, 
spells  out  in  relatively  complete  detail  the  PDSS  responsibilities  of  most 

of  the  involved  organizational  elements  identified  in  the  preceding  paragraph. 
This  document  reflects  a  significant  amount  of  cooperation,  coordination,  and 
thinking  among  the  principal  parties  concerned  with  these  PDSS  issues  for 
PATRIOT.  The  AN/TSQ-73  (Missile  Minder)  Post-Deployment  Management  Plan, 
second  revision,  June  1979,  was  issued  by  the  Configuration  Manager,  Missile 
Minder/Air  Defense  Tactical  Data  Systems,  in  the  office  of  the  Project  Manager, 
MM/ATDS,  C0RADC0M,  Redstone  Arsenal.  (The  first  edition  was  in  May  1977.) 

This  Management  Plan  addresses  both  hardware  and  software  support  following 
deployment.  The  first  20  pages  of  this  document  include  a  fairly  detailed 
overview  of  the  functions  of  the  principal  organizational  elements  involved, 
and  more  detailed  definition  for  the  PM's  Software  Support  Group  (now  Division) 
at  Fort  Bliss,  and  MICOM's  Missile  System  Software  Center  (MSSC)  at  Redstone 
Arsenal.  Responsibilities  of  the  US  Army  Air  Defense  Center  are  reproduced 
in  Figure  2-7.  The  remainder  of  the  document  consists  of  about  160  pages  of 
annexes,  among  which  are  agreements  regarding  the  establishment  and  support 
of  the  Software  Support  Group,  and  a  copy  of  the  configuration  management 
plan,  which  contains  some  additional  detailing  of  responsibilities-  PDSS 
responsibilities  for  the  other  BAS  addressed  in  this  BFA  (SH0RAD  c  ,  DIVAD 
Gun,  I-HAWK,  and  ROLAND,  ADEWS)  are  not  formalized  at  this  time,  except  within 
the  Combat  System  Software  Division,  DCD,  USAADS. 

(4)  Regulatory/di recti ve  authorities.  Listed  below  are  the 
principal  regulations  and  other  documents  which  impact  on  the  TRADOC 
functions  and  responsibilities  relevant  to  PDSS  in  this  BFA. 

t  AR  10-5,  Organization  and  Functions  of  the  US  Army,  1  November  1978 
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2.2.4  US  Army  Air  Defense  Center  and  School,  Ft.  Bliss,  Texas 

2. 2. 4.1  Represents  the  US  Army  AN/TSQ-73  user  community  at  the  MM/ADTDS 
Level  III  Software  Configuration  Control  Board  (SCCB) .  Provides  user  guid¬ 
ance  to  the  SCCB,  the  MM/ADTDS  Software  Support  Group,  and  USA  MIRADCOM 

MS  SC. 

2. 2.4.2  Serves  as  the  interface  between  the  materiel  developer  and  the 

user  community  for  all  matters  pertaining  to  doctrine,  tactics,  and  training. 

2. 2.4.3  Conducts,  with  the  assistance  of  the  MM/ADTDS  Software  Support 
Group  and  USA  MIRADCCM  MSSC,  acceptance  testing  of  software  master  tape 
versions  and  hardware  modifications. 

2. 2.4.4  Participates  in  TM  maintenance  and  validating  activities.  Accepts 
or  rejects  and  recommends  changes  to  the  operational  TM's. 

2. 2.4.5  Establishes,  in  coordination  with  the  materiel  developer  and  the 
AN/TSQ-73  user  community,  the  fielding  date  for  software  master  tape  versions. 

2. 2. 4.6  Establishes  user  priorities  for  implementation  of  software  changes. 
Participates  in  the  establishment  of  priorities  for  the  "Authorized  for 
Implementation"  list  of  ECR' s  for  software  master  tape  versions. 

2. 2.4.7  Originates  system  design  improvement  requirements  and  conceptual 
studies . 

2. 2.4.8  Develops  acceptance  test  procedures. 

2. 2. 4.9  Provides  host  support  for  the  MM/ADTDS  Software  Support  Group. 


Figure  2-  7.  Extract:  ADCEN  responsibilities  for  TSQ-73 
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•  AR  10-41,  Organization  and  Functions,  United  States  Army  Training 
and  Doctrine  Command,  27  June  1973 

•  TRADOC  Regulation  10-41,  Organization  and  Functions,  1  May  1980 

•  USAADS  Regulation  10-1,  Organization  and  Functions 

•  Charter,  Directorate  of  Combat  Developments,  USAADS 

•  Charter,  Directorate  of  Training  Development,  USAADS 

•  Charter,  TSM- PATRIOT 

•  Charter,  TSM-DIVAD  Gun 

•  Charter,  TSM-ROLAND 

•  Charter,  TSM-STINGER 

•  Memorandum  of  Agreement  on  Modification/Validation  of  Operational 
Software  for  US  Army  Air  Defense  Battlefield  Automated  Systems 
Deployed  to  NATO,  Among  the  Commanding  General,  United  States  Army 
Training  and  Doctrine  Command,  and  the  Commanding  General,  United 
States  Army  Materiel  Development  and  Readiness  Command,  and  the 
Commander  in  Chief,  United  States  Army,  Europe  and  Seventh  A. my, 
signed  February  1980 

t  Project  Manager,  Missile  Minder/Air  Defense  Tactical  Data  Systems, 
Redstone  Arsenal,  Alabama,  and  Office  of  the  Program  Manager,  Army 
Tactical  Data  Systems,  Fort  Monmouth,  New  Jersey.  AN/TSQ-73 
(Missile  Minder)  Post-Deployment  Management  Plan,  Second  Revision, 
June  1979 

•  Project  Manager,  PATRIOT  Missile  System,  Redstone  Arsenal,  Alabama. 
Post-Deployment  Software  Support  Implementation  Plan,  June  1980 

•  DOD  Directive  5000.29.  Management  of  Computer  Resources  in  Major 
Defense  Systems.  26  April  1976 

•  AR  70-series 

•  AR  1000-1,  Basic  Policies  for  Systems  Acquisition,  1  April,  1978 

t  Department  of  the  Army,  Office  of  the  Assistant  Secretary,  Research, 

Development  and  Acquisition.  Memorandum  for  Deputy  Chief  of  Staff 
for  Research,  Development,  and  Acquisition,  Subject:  Standardization 
of  Embedded  Computer  Resources.  1  July  1980,  and  letter.  Office 
of  the  Deputy  Commander  TRADOC,  30  July  1980,  same  subject. 


(5)  Relationships  with  Users,  Materiel  Developers,  Training 
Developers.  PDSS  relationships  among  the  Air  Defense  Center,  Users,  Materiel 
Developers,  Training  Developers,  and  others  involved  in  PDSS  of  BAS  are 
relatively  extensive.  In  the  area  of  PATRIOT  and  TSQ-73,  much  effort  has 
been  expended  in  developing  forward  thinking  and  effective  relationships, 
in  spite  of  very  limited  personnel  resources.  A  climate  of  cooperation 
between  TRADOC  and  DARC0M  has,  especially  in  the  last  year  or  more,  aided 
significantly  in  making  this  effort  productive.  While  responsibilities,  and 
resulting  relationships,  are  to  a  considerable  degree  spelled  out  and  supported 
by  the  two  respective  post-deployment  plan  documents  mentioned  in  Paragraph 
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(3),  above,  these  relationships  remain  relatively  informal,  and  dependent  for 
their  effectiveness,  upon  the  individuals  involved.  There  is  evidence  of 
some  concern  that  the  effectiveness  of  these  relationships  could  deteriorate 
if  the  current  climate  of  cooperation  and  common  purpose  were  to  be  damaged 
for  any  reason.  These  relationships,  it  should  be  noted,  basically  involve 
the  broader  area  of  the  overall  combat  development-materiel  acquisition  life 
cycle  process,  of  which  PDSS  is  only  one  aspect.  Effectiveness  of  relationships 
with  Users  appears  to  depend  also  upon  policies  which  ^ave  evolved  in  the 
case  of  TSQ-73.  These  include  active  participation  of  a  combined  Combat 
Developer-Materiel  Developer  team  in  bringing  information  about  the  system, 
and  system  software  changes  directly  to  the  Field  User,  insuring  that  changes, 
related  training  issues,  and  their  implications  are  understood  by  the  User, 
and  that  user  problems  are  understood  and  brought  back,  by  first-hand  contact, 
to  the  site  where  software  support  is  cooperatively  managed  and  implemented. 
Earlier  in  the  PATRIOT  program,  some  serious  obstacles  were  revealed  during 
planning  for  training  and  training  devices.  It  appears  that  some  flexible 
"give  and  take"  between  the  DARCOM  and  TRADOC  parties  has  gone  a  long  way 
toward  solving  some  of  these  problems,  although  resource  constraints  are  a 
continuing  problem.  A  diagram  of  some  of  the  relationships  involved  in 
AN/TSQ-73  is  reproduced  from  the  Post-Deployment  Management  Plan,  in  Figure 
2-8. 


(6)  Operating  procedures.  Fairly  specific  operating  procedures 
for  PDSS  of  the  TSQ-73  have  evolved  at  the  Combat  Systems  Software  Division. 
One  individual  is  devoted  essentially  full-time  to  such  PDSS  functions. 
Although  these  procedures  are  outlined  in  the  Post-Deployment  Plan,  and 
details  are  apparently  not  formalized,  they  amount  to  a  close  working 
relationship  with  the  Software  Support  Division  (belonging  to  DARCOM  and 
located  across  the  street  from  the  building  housing  the  Directorate  of 
Combat  Developments)  and  its  Combat  Systems  Software  Division.  Because  of 
the  complexity  of  the  NATO  integrated  air  defense  system  and  the  inability 
of  CONUS  test  facilities  to  duplicate  that  environment,  it  is  an  operating 
procedure  that  a  validation  test  of  any  software  change  affecting  NATO  be 
conducted  by  USAREUR  or  with  USAREUR  participation,  before  release  of  the 
change  to  the  field.  Configuration  management  procedures  for  TSQ-73  are 
reproduced  in  Figure  2-9. 

(7)  Gaps  and  duplications  in  current  PDSS  process.  Research  to 
date  has  not  revealed  any  significant  gaps  or  duplications  in  the  detailed 
PDSS  processes  outlined  pertaining  to  AN/TSQ-73  and  PATRIOT,  although  there 
is  evidence  that  current  manning  at  USAADS  is  not  consistent  with  the  PDSS 
responsibilities  involved.  Detailed  plans  do  not  exist  for  the  other  air 
defense  systems  which  need  or  will  need  PDSS.  Lack  of  plans  in  some  cases 
simply  reflects  that  the  system  is  in  early  stages.  In  the  case  of  I-HAWK, 
DIVAD  Gun,  and  ROLAND,  however,  a  lack  of  earlier  planning  and  resource 
allocation  appears  to  be  reflected. 


COMMAND  RELATIONSHIPS 
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Figure  2-  8.  Some  TSQ-73  relationships 
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Figure  2-9.  TSQ-73  Configuration  Management (continued  on  next 


2-44 


2  -  3  w  -  ■  -Iq-  KA  7 1  ON  MAN  AG  EM—  NT .  Tr.  •»  -  o ;  i  r  :  ?  ;i  .  r:s  har.-jge.—.tinc  Program,  js 
cur  r-.-:.  r  1/  defined  and  implemented  for  tc.e  ent  cycle,  will  be  -  r  „  - 

through  the  production,  operations,  and  -a  4 .  *  v  •  a:.<_e  cycles.  The  PM  -ZZZ 
will  be  responsible  for  the  overall  Cor.f  uur-tior.  Management  of  the  At.  Tip- 
System  with  the  exception  of  ART.*. 2 5  Ccr-.r.  ,;c-s. 

2.3.1  Configuration  Level  Def  mi  t  .or.  ,-ee  Configuration  Manager  e- 1 

for  Detail  Annex  C) 

2. 3.1.1  Configuration  Level  1 

2. 3. 1.1.1  Controls  configuration  at  the  and  coirjnonality  level  f ; 

ARTADS  Pro  1  rams . 


2.  3.1.1  2  Approval  authority  fer  chir..:«...  a‘  :ve  i  specified  cost  level. 

2. 3. 1.2  Configuration  Level  II 

2.  3. 1.2.1  Approval  authority  for  all  E  ~  •*.  .  .  „  _ther  than  Level  I. 

2. 3. 1.3  Conf iguration  Level  III 


2. 3. 1.3.1  Assess  and  status  ECR’s 
2.  3. 1.3. 2  Prepare  and  submit  ECPs. 

2.  3. 1.3.  3  Recommend  approval/di:  ar ;tov  i  1  tCPs. 

2.3.2  Change  Processing.  Figure  2  d-.  ;  j;ts  •.!  ■■*  chain  of  events  invrL\e*  m 
processing  a  change  request  during  st-  :.p’.  yr-nt  of  the  AN/TSQ-73 

2. 3. 2.1  PM,  MM/ADTDS  will  make  the  initial  it  ter*  i  nation  concerning  the 

application  of  a  hardware,  software,  or  L;:.CJ  ha rdwa re/software  FTA. 
wftr«/M4D  software  ECRs  are  forward*  d  to  .ICC*  MSSC  for  action.  f  r  - 

ECRs  are  forwarded  to  the  MK/ACTC  "  j  oi  t  Troup  at  Fort  =’.  ss, 

for  action.  Tasking  will  range  frem  a  :  ;  *.e  t  •.iking  DF  transmitting  a 

F.CR  t.o  a  full  program  plan  for  a  tys*-.-  r  odi  fi  cation. 


2.  3.2.2  The  ECR  package  prog:  vs  ^*s  through  .»iC  verification,  ccrti  f : -atic  - 

and  acceptance  testing.  For  hardware  changes  the  change  package,  with  its 
appropriate  documentation,  is  made  available  to  the  nmp  for  distribution. 
Distribution  will  be  accomplished  by  NMP  personnel  interacting  with  ARTADS 
field  officers  located  in  the  appropriate  operational  theaters.  For  softwa 
char  res  the  new  tape,  with  its  associated  operational  TM  change  pages  (pro*. 
by  the  NMP)  ar.d  other  appropriate  doc-mentation ,  will  be  distributed  to  the 
user  or  sanitations  by  MM/AD7DS  Software  Support  Group  personnel. 


2.4  TESTING  The  coal  of  the  testing  effort  is  to  insure  that  each  AN/Ti; 
system  i-aie  and  software)  introduced  to  the  field  is  operationally  a: 
The  r.jpts  of  testing  that  this  .mar.ac-.rent  r  lan  applies  to  are: 


1.  Verification  Testing.  Verifies  that  the  design  modification  h  »s  r 
acc..~ plashed  in  accordance  with  the  ECP  pa-.^age  and  the  hardware/sef v-a-e 
system  performs  correctly.  A  separate  t*5t  plan  will  be  prepared  and  sui~. 
as  part  of  the  ECP  package  for  each  raster  tare  version  or  hardware  nod. fi. 


2.  Certification  Testing.  The  AC  7  D5 

of  detailed  :ertif ication  test  procedures  des 
exhaustively  as  possible.  The  test  consists  ^ 
personnel,  hardware,  and  software  which  reacts 
detailed,  step  by  step  procedure  indicating  s;- 
the  expected  results.  The  procedures  win  be 
so  that  the  procedures  correctly  represent  the 
will  consist  largely  of  single  thread  actions 
operation  cf  a  specific  function.  The  test  is 
overall  of f octivcr.ess  of  the  total  system  r 
lr  ii  •••:  J.  .a  1  har.aes.  LSSADS  may  observe  and  r  ; 
’ n  the  ■  ve-t  that  OSA-ADS  elects  not  to  perform 
rjs'vr  :  re  .  ■  -rsior.  or  hardware  mod  if  ica?  •  rn, 
res  hs  of  c.-.e  Tv r* i f ication  Testing  will  ’.  <»  a 


SSG  and  MSSC  will  .maintain  * 
gned  to  exercise  the  system  a 
f  a  real  time  interaction  of 
to  the  inputs  provided  by  a 
vcific  actions  to  be  taken  ar 
opiated  with  each  new  version 
version  under  test.  The  pr: 
designed  to  demonstrate  the 
iesirned  to  demonstrate  the 
or  than  the  testing  of  the 
. tieipate  in  Certification 
Acceptance  Testing  for  a  g: 
w'.v*-;rence  by  USAADS  ir.  tr.e 
val'd  substitute  for  ..  .  -  r*- 


3.  A..C-  i  tance  Testing.  A  procec.no  ;.rii»r  to  the  one  described  ft: 
C«  :  ci  i  . '  o  .on  process  will  be  iir.pl  cm*' **t«d  for  the  acceptance  testing.  The 
essential  difference  is  that  greater  c-phasis  will  be  placed  upon  ut-litd: 
of  act-..  »l  hi:  :**i  re, ‘eguipr.ent/sy  steins  ar.J  t .  Amy  Air  Defense  Cv.tt-r  uni 

Sch.ol  will  insure  the  development  of  systi. ..  c;  rational  test  proce  iires 
which  w:U  be  designed  to  duplicate,  ir,s.  as  iractical,  the  operational 
e:...r"T*,f.t.  The  acceptance  will  tend  to  a  live  environment,  field  i*~: 

’  :T  -  *  >ct  effort  jsing  the  equipment,  «.  •  •  ■ -.s  «..d  personnel  available  to  t‘ 
•-*;’.  \L7Z~  3. f  . ware  Support  Group  ar.d  the  hi  : :  y  A.r  Defense  Center  a-  J  ‘m 
n  Sich  ;  iiprent,  systems  and  perso;...-  1  i*.  i  r.ed  by  L'SAADS .  E  :  ■  i  i: 

th».  projected  availability  date  of  a  :•  «  to:  rape  version,  the  ,  .. 

test  j*riod  will  be  scheduled  well  in  4  !v  v  *.  cf  its  occurrence  for  p’a'-:r 
r  :t  i  oces. _ 


Figure  2-9.  (concluded) 
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e.  Intelligence  and  Electronic  Warfare  BFA. 

(1)  BAS  addressed  within  this  BFA.  The  eight  Category  1  and  2 
BAS  which  impose  requirements  for  planning  and  providing  PDSS  within  this 
BFA  are  identified  and  discussed  briefly  below. 

(a)  AH -Source  Analysis  System  (ASAS).  This  Category  1  system 
which,  under  the  CCS1'  concept,  is  to  serve  as  the  control  system  within 

the  I/EW  BFA,  is  in  the  conceptual  phase.  An  ASAS  LOA  was  prepared  in  January 
1980  and  in  May  1980,  a  MENS  was  prepared.  Consideration  is  now  being  given 
to  further  development  of  this  system  jointly  with  the  US  Air  Force.  It  is 
currently  planned  that  this  development  would  proceed  following  the  evolution¬ 
ary  process  authorized  by  D00I  5000.2. 

(b)  Technical  Control  and  Analysis  Center  (TCAC).  Two  versions 
of  this  system,  TCAC(C)  and  TCAC(D),  are  being  developed  as  Signal  Intelli¬ 
gence  (SIGINT)  Subsystems  (SEWS)  to  the  ASAS.  Development  is  under  QRC-51 , 
directed  by  the  Army  Intelligence  and  Security  Board  under  provisions  of 

AR  105-37. 


(c)  QUICKLOQK  II.  This  is  an  airborne  noncommunications 
emitter  location  identification  system,  employed  by  the  Aerial  Exploitation 
Battalion,  CEWI  Group,  at  the  corps  level.  It  is  a  fielded  system  for  which 
PDSS  is  being  provided.  The  fielding  and  support  of  QUICKLOOK  has  provided 
operational  experience  in  addressing  PDSS  that  should  be  useful  in  planning 
support  for  other  similar  BAS. 

(d)  GUARDRAIL  V.  This  is  an  airborne  SIGINT  system  to  be 
employed  by  the  Aerial  Exploitation  Battalion,  CEWI  Group,  at  the  corps 
level.  This  system  is  an  improved  version  of  earlier  GUARDRAIL  systems. 

Plans  provide  for  completing  a  ROC  for  "GUARDRAIL  IMPROVED"  (i.e.,  GUARDRAIL 
V)  in  January  1981 . 

(e)  Stand  Off  Target  Acquisition  System  (SOTAS).  This  airborne 
SIGINT  system,  currently  in  full  scale  development,  is  to  be  employed  by 

the  CEWI  battalion  at  division  level.  Development  is  proceeding  based  on 
a  Required  Operational  Capability  (ROC)  prepared  in  1978  but  which  is  now 
pending  revision. 

(f )  Electronic  Countermeasure  System  AN/ALQ-151  (QUICKFIX). 
QUICKFIX  is  an  airborne  SIGINT  system,  currently  in  low  rate  initial  pro¬ 
duction,  to  be  employed  in  support  of  divisions  and  armored  cavalry  regiments/ 
separate  brigades.  Development  has  been  based  on  a  ROC  for  Heliborne 
Intercept  and  ECM  System,  November  1973. 
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(g)  Detection  System,  Special  Purpose  AN/TSQ-114  (TRAILBLAZER) . 
This  is  an  airborne  SIGINT  system,  currently  in  low  rate  initial  production, 

to  be  employed  by  the  CEWI  battalion  at  division  level.  A  ROC  of  September 
1979  is  the  basis  for  system  development. 

(h)  Communications  Facility  AN/MSC-67  (COMFAC).  COMFAC  is 
being  developed  to  support  CEWI  Group  (Corps)  special  communications  require¬ 
ments.  It  is  presently  in  the  Validation  Phase.  Development  is  based 

on  a  COMFAC  Letter  Requirement  (LR),  August  1977.  The  US  Army  Intelligence 
Center  and  School  is  the  CD  proponent  for  this  system  during  development. 

The  US  Army  Signal  Center  is  to  become  the  CD  proponent  after  fielding. 

(2)  Organizational  elements  involved  in  planning  for  and 
providing  PDSS.  Organizational  elements  of  the  US  Army  Intelligence  Center 
and  School  (USAICS)  that  have  or  are  projected  to  have  major  responsibilities 
in  planning  for  and  providing  PDSS  to  BAS  in  this  BFA  are  identified  in 
Paragraph  (a),  below.  Other  organizations  within  and  external  to  TRADOC 
with  which  USAICS  personnel  must  interface  to  a  significant  degree  in 
carrying  out  these  PDSS  actions  are  identified  in  Paragraphs  (b)  through 
(e). 


(a)  USAICS  organizations  involved. 

1_.  Directorate  of  Combat  Developments.  This  directorate 
is  involved  as  the  CD  proponent  for  all  BAS  in  the  Intell igence/EW  BFA. 
Subordinate  elements  involved  include  the  Concepts  and  Studies  Division, 
the  Materiel  Division,  the  Threat  Office,  and  the  All -Source  Analysis 
System  Management  Office. 


2.  Directorate  of  Training  Developments.  Elements  of 
this  directorate  are  involved  with  training  developments  determined  to  be 
needed  as  a  result  of  changes  to  BAS  in  this  BFA.  Training  development 
support  for  SIGINT  systems  is  provided  by  the  Intelligence  School,  Fort 
Devens,  Massachusetts. 

_3.  TRADOC  System  Manager  for  specified  Corps  Tactical 
EW/Intel 1 igence  Systems.  This  office  has  the  normal  TSM  responsibilities, 
specified  in  TRADOC  Regulation  71-12,  for  the  corps  level  BAS  identified 
above. 


4.  TRADOC  System  Manager  for  specified  Division  Tactical 
EW/Intelligence  Systems.  This  office  has  the  normal  TSM  responsibility, 
specified  in  TRADOC  Regulation  71-12,  for  the  division  level  BAS  identified 
above. 

5_.  TRADOC  System  Manager  for  Stand  Off  Target 
Acquisition  System  (SOTAS).  This  office  has  TSM  responsibilities,  specified 
in  TRADOC  Regulation  71-12,  for  the  SOTAS. 
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6..  US  Army  Intelligence  and  Security  Board.  This  board 
has  responsibilities  for  tactical  intelligence  and  security  systems 
testing  as  prescribed  in  TRAOOC  Regulation  10-41. 

7_.  Computer  Systems  Management  Office.  It  is  anticipated 
this  office  will  be  assigned  major  responsibilities  for  supporting  all  other 
USAICS  elements  involved  in  planning  for  and  providing  PDSS  for  BAS  as  PDSS 
requirements  increase.  This  support  would  provide  USAICS  an  improved 
capability  to  fulfill  CO  resonsibilities  for  PDSS  to  BAS  in  this  BFA. 

(b)  HQ  TRADQC.  Intel! igence/EW  system  staff  officers  in  the 
Intel! igence/EW  Directorate,  DCSCD,  exercise  HQ  TRADOC  staff  supervision  over 
actions  involving  BAS  in  this  BFA.  USAICS  personnel  must  interface  with  these 
HQ  TRADOC  staff  officers  on  various  matters  involving  intell igence/EW  BAS. 

(c)  CACDA.  The  ASAS  TSM  is  located  in  CACDA.  He  has  TSM 
responsibilities  as  prescribed  by  TRADOC  Regulation  71-12.  The  USAICS  ASAS 
Management  Office  interfaces  with  and  supports  the  TSM  as  required  in 
discharging  CD  responsibilities  associated  with  the  ASAS.  In  addition  USAICS 
personnel  must  interface  with  the  C3I  Directorate  of  CACDA  that  has  respon¬ 
sibility  for  integration  of  efforts  in  the  intell igence/EW,  command,  control, 
and  communications  functional  areas. 

(d)  INSCOM.  USAICS  coordinates  with  INSCOM  with  respect  to 
interface  requirements  and  other  relationships  between  intell igence/EW 
systems  within  the  corps  area  and  systems  at  echelons  above  corps. 

(e)  DARCOM. 

1_.  Electronic  Research  and  Development  Command  (ERADCOM). 
ERADCOM  is  the  Materiel  Development  command  for  all  the  BAS  identified  above 
in  the  Intel  1 igence/EW  BFA.  ERADCOM1 s  Electronic  Warfare  (EW)  Laboratory 
and  the  Signals  Warfare  (SW)  Laboratory  are  both  involved.  Extensive  inter¬ 
action  is  needed  between  USAICS  and  ERADCOM  personnel  in  fulfilling  their 
respective  CD  and  MD  roles  during  system  development  and  post-deployment 
support. 


2_.  Troop  Support  and  Aviation  Readiness  Command. 
Since  several  of  the  BAS  in  the  Intell igence/EW  BFA  are  airborne  systems, 
USAICS  personnel  must  interact  with  TSARCOM  on  matters  related  to  these 
platforms. 


(f)  US  Army  Communications  Command  (USACC).  An  element  of 
USACC,  the  US  Army  Communications  and  Electronics  Engineering  and  Installation 
Agency  (USACEEIA),  has  taken  over  responsibility  from  the  original  contractor 
for  development  of  COMFAC.  There  is  close  interaction  between  CEEIA  COMFAC 
developers  and  the  USAICS  COMFAC  action  officer. 
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(g)  Users.  USIACS  systems  personnel  must  interact  with 
systems  users  in  identifying,  analyzing,  and  addressing  system  problems  and 
user-initiated  change  proposals. 

(3)  Responsibilities/Charters.  USAICS  is  the  CD  proponent  for 
all  BAS  in  the  Intel! igence/EW  BFA.  Within  USAICS,  this  responsibility  is 
further  assigned  to  the  Directorate  of  Combat  Developments.  With  respect 
to  PDSS  for  these  Intell igence/EW  BFA  BAS,  basic  responsibilities  are  the 
same  as  those  identified  in  Figure  2-5.  Responsibilities  of  the  three  TSM 
in  USAICS  (i.e.,  Corps  Systems,  Division  Systems,  and  SOTAS)  and  the  TSM 
ASAS  in  CACDA  are  as  prescribed  in  TRADOC  Regulation  71-12. 

(4)  Regulatory/di recti ve  authorities.  The  principal  regulatory 
authorities  from  which  the  above  responsibilities  derive  are  those  cited 
in  Paragraph  2-2. b.  Most  significant  among  these  are: 

•  DODD  5000.1 

•  DODI  5000.2 

•  AR  10-41 

•  AR  70-1 

•  AR  1000-1 

•  TRADOC  Regulation  10-41 

•  TRADOC  Regulation  71-12 

•  DA  Pamphlet  11-25 

•  USAICS  Regulation  10-1. 

(5)  Operating  Procedures.  Among  the  eight  Category  1  and  2 
Intell igence/EW  BAS  are  three  deployed  systems.  Other  systems  are  in 
various  stages  of  development.  This  distribution  of  systems  in  various  life 
cycle  phases  provides  a  good  basis  for  examining  CD  involvement  throughout 
the  system  life  cycle  management  process. 

(a)  The  Materiel  Division  of  the  Directorate  of  Combat 
Developments  has  CD  responsibility  for  development  of  new,  or  improvement 
of  existing,  materiel  systems  for  tactical  electronic  warfare  and  tactical 
intelligence  organizations.  The  Corps,  Division,  and  EAC/Common  Systems 
Branches  of  this  division  have  Action  Officers  who  are  assigned  CD  respon¬ 
sibility  for  one  or  more  Intelligence/EW  BAS.  These  officers  perform  a 
broad  range  c  ^unctions  and  interact  with  a  number  of  other  organizations 
as  described  ,  Paragraph  2-4. b. (2),  above.  These  branch  Action  Officers, 
together  with  the  respective  TSMs,  represent  the  focal  point  for  CD  involve¬ 
ment  in  the  life  cycle  management  of  Intelligence/EW  BFA  BAS. 

(b)  During  system  development,  operations  proceed  essentially 
as  prescribed  by  regulatory  and  directive  authority.  The  CD  systems  Action 
Officers  participate  in  systems  planning  activities,  defining  functional 
requirements,  system  testing,  identifying  training  development  requirements, 
and  other  related  actions.  After  fielding,  however,  with  few  exceptions, 
system  changes  are  accomplished  primarily  through  interaction  between  Users 
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and  the  MD  or  in  some  cases  with  the  contractor  who  developed  and  maintains 
the  system.  ERAOCOM  coordinates  with  USAICS  for  validation  of  system  change 
requirements,  but  the  primary  dialog  with  respect  to  system  changes  occurrs 
between  the  User  and  the  MD.  In  one  case,  in  which  major  problems  were 
encountered  with  the  QUICKLOOK  system  in  Europe,  USAICS  CD  system  personnel 
were  sent  to  make  an  on-site  analysis  of  the  problems  as  a  basis  for 
formulating  corrective  action  with  the  MD.  However,  this  type  of  direct 
User-CD-MD  interaction  appears  to  be  limited.  Available  information  indicates 
that  increased  interaction  is  needed  at  the  working  level  between  the  CD 
and  User  and  the  CD  and  MD  throughout  the  system  life  cycle  process. 

(6)  Gaps  and  duplications  in  current  PDSS  process. 

(a)  There  are  no  apparent  duplications  of  effort  within  the 
intelligence  CD  community  or  between  the  CD  and  either  the  Users  or  MD  with 
respect  to  Intel  1 igence/EW  BAS  life  cycle  management. 

(b)  Gaps  or  potential  gaps  exist  in  some  functional  areas. 
First,  is  the  apparent  limited  participation  of  the  CD  in  addressing  User- 
reported  system  problems  and  proposed  system  changes.  This  area  was  discussed 
in  Paragraph  (5),  above.  A  second  area  of  concern  is  the  capability  of  the 

CD  to  define  functional  system  requirements  in  the  detail  desired  and  needed 
by  the  MD  to  guide  the  system  development  and  subsequent  system  change  efforts. 
A  third  area,  related  to  both  of  those  above,  is  the  limited  capability  to 
fully  analyze  both  the  need  for  and  the  impact  of  system  changes  as  a  result 
of  changes  in  the  threat,  doctrine,  operational  requirements  or  interoper¬ 
ability  baseline.  The  CO  requirements  resulting  from  these  limitations  are 
discussed  in  Paragraph  3-5. d..  Chapter  3. 

f .  Combat  Service  Support  BFA. 

(1 )  US  Army  Logistics  Center. 

(a)  BAS  addressed  within  this  BFA.  The  BAS  in  the  logistics 
portion  of  the  Combat  Service  Support  BFA  which  impose  PDSS  requirements  on 
the  US  Army  Logistics  Center  (LOGCEN)  are  identified  and  discussed  briefly 
below.  Additional  detail  on  each  of  these  systems  is  provided  in  Appendix  C. 

1_.  Direct  Support  Unit  Standard  Supply  System  (DS4). 

This  is  an  Army-wide  multicommand  system  designed  to  automate  stock  control 
and  provide  an  improved  asset  management  capability  at  the  division  and 
nondivisional  direct  support  unit  level  and  at  selected  general  support  unit 
sites.  The  system  is  operational  and  is  scheduled  to  replace  two  other 
systems— the  Direct  Support  Unit/General  Support  Unit  (DSU/GSU)  System  and 
the  Division  Logistics  System  (DLOGS)— both  of  which  are  discussed  below. 

The  requirements  document  for  this  system  is  Detailed  Functional  System 
Requirements  (DFSR),  TM-38-L32-2  (Test),  July  1976. 


2-50 


2.  Direct  Support  Unit/General  Support  Unit  (DSU/GSU). 

This  is  one  of  the  Army's  first  automated  multicommand  information  systems. 

It  became  operational  in  1966  to  support  stock  control  and  inventory  accounting 
at  the  direct  and  general  support  levels.  The  system  is  being  phased  out  as 
replacement  DS4  systems  are  deployed. 

3.  Division  Logistics  System  (DLOGS).  DLOGS  is  a 
multicommand  ADP  system  designed  to  apply  automated  methods  to  division  level 
asset  management.  It  became  operational  in  1968.  The  system  is  being  phased 
out  as  DS4  systems  are  deployed. 

4_.  Standard  Army  Ammunition  System  Level  3  (SAAS-3). 

SAAS  is  a  standard  multicommand  conventional  ammunition  supply  and 
maintenance  management  information  system.  SAAS-1  is  currently  operational 
at  the  major  command  level  in  USAREUR  and  in  the  Pacific.  SAAS-3  is  to  be 
a  feeder  system  employed  in  tactical  commands  and  other  commands  below 
theater  level.  It  will  be  used  to  exercise  stock  control  over  assets  of  one 
or  more  activities.  Development  of  SAAS-3  is  under  the  DFSR  for  SAAS-3 
which  was  approved  in  September  1979. 

5_.  Standard  Army  Intermediate  Level  Supply  (SAILS) 

System.  SAILS  is  a  multicommand,  integrated,  automated  supply  and  financial 
management  system.  By  selective  employment  of  system  modules,  selective 
exercise  of  managerial  controls,  and  optional  frequency  of  running  selected 
modules,  SAILS  supports  supply  requirements  at  the  intermediate  level.  SAILS 
Level  A  (supply  management)  and  Level  B  (storage  operations)  are  used  by 
various  command  levels  including  Corps  Support  Commands  (C0SC0M).  The  various 
SAILS  subsystems  and  baselines  are  to  be  incorporated  into  a  single  worldwide 
SAILS  baseline  (SAILS  ABX).  Extension  of  the  SAILS  capability  to  Field 
Users  will  be  completed  in  1982. 

6.  Standard  Army  Maintenance  System  (SAMS).  SAMS  is  an 
automated  logistical  management  information  system  supporting  maintenance 
management  functions  from  the  direct  support/general  support  retail  level 
upward  through  each  succeeding  level  of  management.  SAMS  is  in  the  Conceptual 
Phase  of  development.  The  DFSR  for  the  retail  level  portion  of  this  system 
was  approved  in  November  1979. 

7_.  Division  Level  Data  Entry  Device  (DLDED).  The  DLDED 
is  an  interim  standard  multicommand  system  which  will  support  supply,  mainte¬ 
nance,  and  administration  within  the  division.  Development  is  proceeding 
based  on  a  ROC  of  August  1979.  The  U.S.  Army  Signal  Center  is  the  proponent 
agency  for  the  DLDED.  However,  the  system  is  to  support  logistical  functional 
application  systems  to  include  DLOGS  and  its  follow-on,  DS4,  and  the  Main¬ 
tenance  Reporting  and  Management  (MRM)  System  and  its  follow-on,  SAMS. 

Operation  of  the  DLDED  in  support  of  these  logistical  application  systems 
will  involve  functional  systems  personnel  at  the  LOGCEN. 


8..  Decentralized  Automated  Service  Support  System  (DAS3). 
This  is  a  data  processing  hardware  configuration  for  supporting  the  functional 
software  requirements  of  the  DS4  described  above.  The  DAS3  will  replace  the 
NCR  500  system  in  OSU/GSU  units  beginning  in  late  1981.  Subsequently,  it  will 
be  introduced  into  other  nondivisional  DSU/GSU  and,  depending  upon  further 
study,  into  divisions,  separate  brigades,  and  COSCOM. 

9.  Maintenance  Reporting  and  Management  (MRM)  system. 

This  is  a  maintenance  workload  and  modification  work  order  accounting  system 
at  the  division  level.  It  is  scheduled  to  be  phased  out  as  the  SAMS  becomes 
operational . 

•  10..  Combat  Service  Support  Control  System  for  CCS  . 
Preparatory  combat  development  work  on  this  control  system  architecture  is 
already  underway.  The  LOGCEN  has  been  tasked  to  take  the  lead  role  in  the 
design  and  development  of  this  system  with  inputs  from  the  coordinating  pro¬ 
ponents,  the  Soldier  Support  Center  and  the  Academy  of  Health  Sciences. 

1 1 .  Phoenix.  Phonix  is  a  software  enhancement  of  the 
DSU/GSU  (NCR  500)  system  discussed  in  2  above.  It  was  generated  to  provide 
an  improved  applications  capability.  Its  extension  to  Users  began  in  1979 
and  is  to  cpntinue  with  extension  to  units  in  Europe  and  Korea  in  January 
and  February,  1981,  respectively.  The  DAS3,  discussed  in  8  above,  will 
accommodate  this  software  enhancement. 

(b)  Organizational  elements  involved  in  planning  for  and 
providing  PDSS.  Organizational  elements  of  the  US  Army  Logistics  Center  that 
have  major  responsibilities  in  planning  for  and  providing  PDSS  to  BAS  in  the 
logistics  portion  of  the  Combat  Service  Support  BFA  are  identified  in  Paragraph 
1_. ,  below.  Other  organi zations  within  and  external  to  TRAD0C  with  which  LOGCEN 
personnel  must  interface  to  a  significant  degree  in  carrying  out  their  PDSS 
responsibilities  are  identified  in  Paragraphs  2  through  below. 

1_.  LOGCEN  organizations  involved.  Included  in  the 
mission  of  the  LOGCEN  is  responsibility  to  develop  and  coordinate  the  func¬ 
tional  design,  installation,  and  maintenance  of  multicommand  intermediate  and 
user  logistics  operating/management  information  systems  and  provide  customer 
assistance  in  connection  with  these  systems.  Within  the  LOGCEN,  responsibility 
for  carrying  out  this  mission  is  concentrated  primarily  in  the  Management  In¬ 
formation  Systems  Directorate.  This  directorate  consists  of  a  Management 
Support  Office  and  two  major  divisions--the  Field  Systems  Division  and  the 
Supply  Systems  Division. 


a..  Management  Support  Office.  With  respect  to  BAS 
in  the  logistics  functional  area,  principal  functions  of  this  office  include 
serving  as  the  focal  point  for  special  projects,  studies,  and  plans  for  pro¬ 
posed  systems  having  multifunction  logistics  application;  assuring  standardized 
preparation,  identification,  and  maintenance  of  all  products/deliverables  appli 
cable  to  each  Army  Management  Information  System;  and  performing  distribution 
management  for  publications  on  all  data  systems  for  which  LOGCEN  has  proponency 


2-52 


b.  Field  Systems  Division.  This  division  performs 
combat  developer  functions  associated  with  all  phases  of  the  management  infor¬ 
mation  system  life  cycle,  as  defined  by  AR  18-1,  for  retail  level  supply, 
maintenance,  and  transportation  systems.  These  systems  include  SAAS,  SAMS, 
and  MRM.  With  respect  to  the  Deployment  and  Operation  Phase  of  the  system 
life  cycle,  this  division  performs  a  broad  range  of  functions  to  support 
assigned,  deployed  systems.  These  include: 

•  Preparing  the  necessary  functional  guidance  to  implement  proponent 
agent  approved  changes 

•  Performing  those  functions  (e.g.,  functional  guidance,  changes  to 
regulations,  test  requirements,  user  documentation,  training  require¬ 
ments)  required  to  implement  major  changes  to  existing  systems 

•  Providing  technical  assistance  to  the  users  of  assigned  operating/ 
management  information  systems  and  updating  functional  user 
procedures  as  required 

•  Reviewing  changes  or  proposed  changes  to  Army  regulations,  tech¬ 
nical  documents,  logistics  doctrine,  organization,  systems,  and 
materiel  concepts  for  impact  on  multicommand  intermediate  and 
user  level  operating/management  information  systems  and  providing 
an  impact  statement  to  the  proponent  agent 

0  Developing  test  requirements  and  participating  in  live  tests  at 
designated  instal lation(s)  prior  to  final  acceptance  of  systems 
change  packages  or  emergency/urgent  change  packages  for  assigned 
systems  as  required 

•  Chairing  System  Change  Request  (SCR)  (or  Engineering  Change 
Proposal  (ECP) )  reviews  for  assigned  systems. 

c.  Supply  Systems  Division.  This  division  performs 
Combat  Developer  functions  associated  will  all  phases  of  the  management  infor¬ 
mation  system  life  cycle  for  all  intermediate  and  user  level  supply  systems, 
except  ammunition.  These  systems  include  SAILS,  DLDED,  DS4 ,  DSU/GSU,  and 
DLOGS.  During  the  Deployment  and  Operation  Phase  of  the  system  life  cycle, 
this  division  performs  essentially  the  same  functions  as  enumerated  in 
Paragraph  (2),  (a)  through  (f)  above,  for  assigned  intermediate  and  user 
level  supply  systems. 

2.  Deputy  Chief  of  Staff  for  Logistics,  Department  of 
the  Army  (DCSLOG  DA).  The  LOGCEN  maintains  close  coordination  with  DCSLOG, 
the  functional  proponent  for  the  logistics  systems  addressed  in  this  study. 

3_.  U.S.  Army  Computer  Systems  Command  (CSC).  CSC  is 
responsible  for  the  design,  development,  programming,  testing,  installation, 
maintenance,  and  improvement  of  all  logistics  BAS  addressed  in  this  study. 

A  major  element  of  CSC,  the  Computer  Systems  Command  Support  Group,  Fort  Lee, 
is  assigned  this  responsibility.  The  headquarters  and  major  elements  of  this 
CSC  Support  Group  are  physically  located  near  the  LOGCEN  Management  Informa¬ 
tion  Systems  Directorate  in  Somervell  Hall.  This  facilitates  a  close  working 
relationship  and  continuous  interaction  between  these  organizations  throughout 
a  systems  life  cycle  including  providing  customer  assistance  during  post-de¬ 
ployment. 
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4.  Users.  Management  Information  Systems  Directorate 
Personnel  interface  with  systems  Users  extensively.  This  interaction  with 
Users  involves  addressal  of  user-reported  system  problems  and  functional 
requirements.  It  also  includes  planning,  scheduling,  coordinating,  and 
participating  in  customer  assistance  visits  to  System  Users  Army-wide. 

(c)  Responsibili ties /charters.  The  LOGCEN  is  designated 
the  proponent  agency  (PA)  for  all  logistics  BAS  addressed  in  this  study.  As 
such,  the  LOGCEN  is  responsible  for  the  functional  design,  development, 
implementation,  and  maintenance  of  these  systems.  DCSLOG  DA  is  the  functional 
proponent  for  these  systems.  CSC  is  the  assigned  responsible  agency  (ARA). 

ARA  responsibilities  include  design,  configuration  management,  development, 
test,  deployment,  and  maintenance  of  assigned  systems. 

(d)  Requlatory/di recti ve  authorities.  The  principal 
regulatory  authorities  applicable  to  the  organizational  responsibilities 
discussed  above  and  the  life  cycle  management  of  BAS  in  the  logistics 
functional  area  include: 

•  AR  10-5 

•  AR  10-41 

•  AR  18-1 

•  TRADOC  Regulation  10-41 

•  LOGCEN  Regulation  10-1 

a  CSC  Regulation  18-21 

•  CSC  Regulation  18-23 

(e)  Operating  procedures.  The  LOGCEN  and  CSC  have  had 
years  of  experience  in  developing,  fielding,  and  supporting  logistics 
systems  and  have  well  established,  documented  procedures  for  all  aspects  of 
this  support.  Further,  the  collocation,  at  Fort  Lee,  of  elements  of  both 
commands  involved  with  the  development  and  life  cycle  management  of 
logistics  management  information  systems  facilitates  a  very  close  working 
relationship  between  personnel  of  both  organizations  throughout  a  systems 
life  cycle.  Most  importantly  users  benefit  from  this  close  relationship 
which  contributes  to  the  overall  capability  to  respond  to  user  problems, 
and  address  functional  system  requirements  and  proposed  changes  in  a 
systematic  manner. 


1_.  System  changes. 

a_.  Source  of  changes.  Requirements  for  changes 
to  logistics  systems  can  orginate  at  any  level.  They  may  grow  out  of  a 
user-reported  problem  or  a  user-initiated  change  request  to  satisfy  a 
functional  requirement.  Additionally,  system  action  officers  in  the 
LOGCEN  Management  Information  Systems  Directorate  routinely  review  changes 
or  proposed  changes  in  Army  regulations,  technical  manuals,  logistics 
doctrine,  organization  and  materiel  concepts,  and  other  automated  systems, 
for  any  impact  on  logistics  systems  for  which  they  are  responsible. 
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b_.  Change  control  process.  Each  formalized  change 
proposal  is  classified  as  either  a  functional  change  (primarily  the  respon¬ 
sibility  of  LOGCEN)  or  a  technical  change  (primarily  the  responsibility 
of  CSC).  All  change  proposals  are  then  addressed  by  a  review  board  composed 
of  representatives  of  all  organizations  concerned  (e.g.,  LOGCEN,  CSC,  User 
Commands,  OCSLOG  DA,  ACSAC  DA).  Approved  changes  are  then  prioritized  and 
a  schedule  established  for  their  development  and  extension  to  the  field  in 
a  system  change  package  (SCP)  along  with  appropriate  user  instructions  and 
functional  and  technical  training  materials.  Major  changes  require  the 
development  of  a  Mission  Element  Needs  Statement  (MENS)  and  Functional  and 
Data  Requirements  Documents  to  support  the  change.  All  changes  undergo 
appropriate  testing  involving  both  LOGCEN  and  CSC  elements  and  a  selected 
user  before  installation  of  the  change  on  fielded  systems. 

2.  User  assistance.  Assistance  to  users  of  logistics 
systems  is  available  on  a  continuous  basis  through  the  LOGCEN  Management 
Information  Systems  Directorate  and  the  Customer  Assistance  Office  operated 
by  the  Data  Services  Directorate,  CSC  Support  Group,  Fort  Lee.  The 
Customer  Assistance  Office  operates  24-hours  per  day,  seven  days  per  week, 
to  receive  and  respond  to  User  guidance  calls  or  incident  reports.  CSC 
Regulation  18-21  establishes  the  policies,  responsibilities  and  procedures 
governing  this  customer  assistance  program. 

(f)  Gaps  and  duplications  in  current  PDSS  processes.  There 
are  no  apparent  significant  gaps  in  current  PDSS  processes  associated  with 
BAS  in  the  logistics  functional  area.  The  close  working  relationship  between 
the  LOGCEN  and  the  CSC  Support  Group,  Fort  Lee,  provides  for  well  coordinated 
efforts  in  their  respective  areas  of  responsibility  and  minimizes  the 
likelihood  of  significant  gaps  or  duplications  occurring. 

(2)  Soldier  Support  Center. 

(a)  BAS  addressed  within  this  BFA.  Battlefield  automated 
systems  which  are  anticipated  to  have  a  significant  impact  on  PDSS  resource 
requirements  within  this  BFA  at  Soldier  Support  Center  are  identified  below: 

1.  Standard  Install ati on/Di vision  Personnel  System 
(SIDPERS)  and  SIDPERS  Wartime.  Although  MILPERCEN  appears  to  be  officially 
the  "proponent  agency'”3  of  both  of  these  systems  (SIDPERS  Wartime  is  a  wholly 
nested  subset  of  SIDPERS,  which  is  fully  fielded),  and  also  performs  essen¬ 
tially  all  Combat  Developer  functions  (including  training  and  software  support) 
for  them,  these  systems  nevertheless  appear  to  require  a  low  level  of  monitor- 
ship  by  Soldier  Support  Center,  which  may  properly  be  called  the  "functional 
proponent"^.  The  principal  reason  for  such  monitorship  is  the  perceived  need 


3 

The  terms  "proponent  agency"  and  "functional  proponent"  appear  in  the 
current  AR  18-1,  15  August  1980,  and  are  discussed  further  in  Paragraphs  (c) 
and  (g),  below. 
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for  a  new  personnel  system,  for  which  the  Soldier  Support  Center  is  likely 
to  be  the  proponent  and  Combat  Developer.  Such  a  new  system  is  separately 
identified  below. 


2_.  Division  Level  Data  Entry  Device  (DLDED)  Personnel 
Software  Package.  While  proponency  for  DLDED  hardware  itself  resides  with 
the  Signal  Center,  the  Personnel  Software  Package  for  DLDED  is  distinct.  It 
is  seen  as  becoming  a  part  of  SIDPERS.  Although  MILPERCEN  is  anticipated 
to  be  involved  with  this  package  in  FY  81  and  FY  82,  and  to  be  relatively 
heavily  involved  during  fielding  of  the  system  in  FY  83,  Soldier  Support 
Center  currently  has  had  and  continues  to  have  personnel  devoted  to  prepar¬ 
ation  of  functional  specifications  and  planning  for  the  Personnel  Software 
Package.  Soldier  Support  Center  involvement  is  anticipated  to  continue 
after  FY  83. ?  The  DLDED  hardware  will  have  related  applications  in  connection 
with  the  CCS^  CSS  Control  System,  and  also  PLRS/JTDS  Hybrid. 

2_.  DAS3  and  other  new  main  hardware:  Software  Conver¬ 
sion.  Switching  from  existing  IBM  360/30  (C53)  to  new  Honeywell  Series  60 
(level -360/50  6  Model  47)  hardware  in  the  FY  83-84  period  will  require 
extensive  software  conversion  and  testing  for  SIDPERS.  A  need  for  monitor- 
ship  by  Soldier  Support  Center  is  seen  in  FY  82,  followed  by  heavier  in¬ 
volvement  during  the  hardware  switching  period,  and  then  some  software 
maintenance  responsibility.  The  need  to  maintain  software  compatibility 
during  hardware  changes  is  also  involved  in  CCSVSIGMA. 

4.  CSS  Control  System  for  CCS2.  Preparatory  combat 
development  work  on  this  control  system  is  already  underway,  and  seen  to 
continue  through  FY  81,  followed  by  continued  CD  responsibilities  during 
development  of  the  system  in  the  FY  82-84  period.  L0GCEN  has  been  tasked 
to  take  the  lead  role  in  development  of  this  system;  however,  SSC  is  tasked 
for  development  of  architectural  input  to  the  design  of  the  CSS  control 
system. 


5_.  A  new  personnel  system  (SIDPERS  Future).  Reference 
to  this  system  was  made  under  SIDPERS,  above.  Requirements  definition  for 
this  new  system  will  require  significant  resources  in  FY  81,  with  substan¬ 
tially  increased  effort  in  FY  82,  and  further  increase  during  development  in 
FY  83-84.  A  substantial  maintenance  effort  will  be  required  thereafter. 

This  system  must  address  dynamic  issues  of  personnel  losses  and  replace¬ 
ments,  and  also  returns  to  duty  from  the  medical  system. 

6.  Personnel  interfaces  with  the  Theater  Army  Medical 
Management  and  Information  System  (TAMMIS).  TAMMIS,  under  development  by 
Health  Services  Command,  will  be  a  source  of  critically  needed  input  data 
in  a  new  personnel  system  (above).  Insurance  that  appropriate  interfaces 
are  achieved  will  require  some  Soldier  Support  Center  effort,  particularly 
in  the  FY  82-84  period. 
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7.  Prisoners  of  War  Information  System  (PWIS).  In¬ 
tegrating  responsibilities  of  the  Soldier  Support  Center  require  some 
involvement  in  this  system.  The  MP  Center  is  proponent  of  this  system, 
which  is  a  subsystem  of  the  Military  Police  Management  Information  System 
(MPMIS).  The  latter  system,  however,  does  not  involve  battlefield  functions. 

8.  The  Vertical  Force  Development  Management  Infor¬ 
mation  System  (VFDMIS).  Soldier  Support  Center  is  only  peripherally 
involved  with  this  system  . 

£.  Theater  Army  Personnel  Rollup  (TAPER)  and  TAPER 
Wartime.  Soldier  Support  Center  has  an  integration  role  in  this  system  which 
serves  only  HQ,  USAREUR.  Study  may  be  required  during  FY  81. 

1 0.  The  Vertical  The  Army  Authorization  Document  System 
(VTAADS).  Soldier  Support  Center  responsibilities  with  respect  to  VTAADS 
are  essentially  covered  under  SIDPERS. 

(b)  Organizational  elements  involved  in  planning  for  and 
providing  PDSS.  Those  organizational  elements  which  currently  appear  to  be 
in  any  significant  way  directly  involved  in  planning  for  or  providing  PDSS 
for  those  BAS  identified  above,  within  the  personnel  and  administration 
portion  of  this  BFA,  fall  in  seven  areas.  These  areas  are  SSC,  MILPERCEN, 
Computer  Systems  Command,  Health  Services  Command,  TRADOC,  DCSPER,  and  Users. 
Specific  organizational  elements  are  identified  below.  User  elements 
generally  have  not  been  identified. 

1_.  Management  Information  Systems  Division,  Directorate 
of  Doctrine  and  Combat  Development,  US  Army  Institute  of  Personnel  and 
Resource  Management,  SSC.  This  element  is  involved  to  varying  degrees  with 
all  of  the  BAS  identified  above,  from  a  combat  development  standpoint. 

2.  Directorate  of  Training  Development,  US  Army 
Institute  of  Personnel  and  Resource  Management,  SSC. 

3.  Field  Military  Systems  Branch,  Field  Activities 
Division,  Personnel  Management  Systems  Directorate,  MILPERCEN.  This 
element  is  involved  with  SIDPERS  and  DLDED. 

4.  Procedures  and  Regulations  Review  Branch,  Field 
Activities  Division,  Personnel  Management  Systems  Directorate,  MILPERCEN. 

5_.  TACMIS  Project  Management  Office,  Computer  Systems 
Command.  This  element  is  the  system  Materiel  Developer  for  DLDED,  DAS3,  and 
related  systems. 
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£.  Personnel  Systems  Division,  Personnel  and  Force 
Accounting  Directorate,  Computer  Systems  Command.  This  element  is  the 
System  Materiel  Developer  for  SIDPERS,  VFDMIS,  TAPER,  and  VTAADS. 

7_.  Systems  Design  Branch,  US  Army  Academy  of  Health 
Sciences.  This  element  performs  the  Combat  Developer  functions  for  TAMMIS. 

8.  Health  Care  Systems  Support  Activity,  US  Army 
Health  Services  Command.  This  element  performs  the  System/Materiel  Develop¬ 
er  functions  for  TAMMIS. 

£.  Commander,  US  Army  Soldier  Support  Center 

10.  Commander,  US  Army  Military  Personnel  Center 

1 1 .  Commander,  US  Army  Training  and  Doctrine  Command 

1 2.  Deputy  Chief  of  Staff  for  Personnel 

(c)  Responsibilities/charters.  Responsibilities  and  charters 
directly  impacting  on  current  and  potential  PDSS  activities  relating  to  the 
Soldier  Support  Center  portion  of  this  BFA  have  recently  been  in  a  state  of 
flux.  Further  significant  changes  are  possible,  and  some  areas  remain 
unclearly  defined.  Responsibilities  of  the  Soldier  Support  Center  were 
broadened  somewhat  by  the  revised  TRADOC  Regulation  10-41,  dated  1  May  1980, 
which  superseded  the  earlier  version  of  15  August  1973.  The  revised 
regulation  designates  Soldier  Support  Center  (Formerly  ADMINCEN)  as  one  of 
three  TRADOC  integrating  centers  (the  other  two  are  the  Combined  Arms  Center 
and  the  Logistics  Center).  The  integrating  center  concept  makes  Soldier 
Support  Center  a  major  subordinate  element  of  TRADOC,  to  ensure  the  systematic 
integration  of  combat  and  training  developments  functions  within  the  broad 
operational  area  of  administration.  Soldier  Support  Center  is  thereby  the 
proponent  for  operational  concepts,  organizations  and  force  structures, 
materiel  requirements,  doctrine,  tactics,  training  developments,  and  user 
testing,  in  assigned  functional  areas.  Also,  by  this  regulation,  the 
center  commander  "may  task  and  provide  guidance  to  other  Army  combat  and 
training  development  activities,  schools,  MACOM,  and  the  field  operating 
agencies  of  the  DA".  Among  the  general  missions  and  functions  of  integrating 
centers,  one  of  particular  relevance  is,  "Perform  continuous  analysis, 
evaluation,  and  assessment  of  TRADOC  combat  development  requirements  to 
ensure  the  effectiveness  of  tactics,  organizations,  and  systems;  and  to 
assist  in  planning  and  programming  for  their  integration  into  the  Army". 

The  regulation  specifically  grants  Soldier  Support  Center  a  coordination 
relationship  with  the  Academy  of  Health  Sciences.  Among  the  several  missions 
specifically  provided  to  the  CG,  Soldier  Support  Center,  the  following 
three  appear  to  be  of  particular  relevance  from  the  standpoint  of  PDSS: 

"b.  Serve  as  the  TRADOC  executive  agent  to  ensure  personnel  issues  are 
addressed  in  the  materiel  acquisition  process." 
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"d.  Develop,  review,  and  evaluate  all  concepts  and  doctrine  pertaining 
to,  or  impacting  upon,  personnel  management  and  services, 
administrative  management  and  services,  financial  management  and 
services,  and  related  computer  based  information  systems." 

"e.  Develop  and  coordinate  the  functional  design,  evaluation,  and 
extension  of  battlefield  administration  management  information 
systems  applicable  to  the  corps  level  and  below." 

The  relationships  between  TRADOC  and  other  commands  are  further  delineated 
in  AR  10-41  of  1  July  1973.  Specifically,  "TRADOC  will  task  and  coordinate 
combat  development  activities  of  other  major  Army  commands  whose  combat 
development  responsibilities  are  delineated  in  AR  71-1.  Combat  development 
products  of  other  Army  commands  and  agencies  will  be  provided  to  TRADOC 
for  integration  into  the  overall  combat  development  effort".  In  Paragraph 
(b)  1_. ,  above,  the  Management  Information  Systems  division  at  Soldier  Support 
Center  was  identified  as  a  principal  organizational  element  involved  in 
planning  for  and  providing  PDSS,  although  their  involvement  has  only  recently 
begun.  At  Soldier  Support  Center,  responsibilities  that  would  appear  to 
relate  to  PDSS  seem  to  fall  almost  entirely  within  that  Division,  one  of 
more  than  eight  such  entities  within  the  Directorate  of  Doctrine  and  Combat 
Development.  The  MIS  Division  is  currently  authorized  35  personnel  and  has 
18  on  hand.  Its  responsibilities  include  development  of  an  overall  battle¬ 
field  administration  automation  architecture  (BA3),  as  well  as  addressal , 
from  a  combat  developments  viewpoint,  of  the  planning  and/or  other  aspects 
of  a  number  of  specific  automated  systems,  including  those  identified  in 
Paragraph  (a)  above.  The  charter  of  this  division  is  contained  in  the 
charter  of  the  Directorate  of  Doctrine  and  Combat  Development. 

On  5-7  August  1980,  a  memorandum  of  understanding  (MOU)  was 
signed  by  the  DCSPER,  the  Commander  TRADOC,  the  Commander  MILPERCEN,  and  the 
Commander  Soldier  Support  Center.  This  MOU  defines  and  realigns  certain 
functional  responsibilities  and  boundaries  between  MILPERCEN  and  Soldier 
Support  Center,  and  specifies  transfer  of  spaces,  authorizations  and  other 
resources  attendant  to  the  realignments.  Much  of  the  content  (Annexes  C  thru 
J)  of  this  MOU  appears  to  deal  with  functions  other  than  those  having  direct 
implications  for  PDSS.  Annex  A,  however,  addresses  the  function  entitled 
"Develop  Future  Standard  Multicommand  Personnel  and  Administrative  Infor¬ 
mation  Systems".  This  annex  indicates  that  MILPERCEN  is  to  have  respon¬ 
sibilities  for  coordination  and  review  with  ODCSPER  and  SSC  in  conjunction 
with  the  Initiation,  Concept  Development,  Definition/Design,  and  System 
Development  Phases,  and  more  specific  responsibilities  in  the  Deployment/ 
Operation  Phase.  These  specific  responsibilities  include  (1)  ensuring  that 
implementation  plans  are  sufficient  and  functionally  correct,  (2)  extending 
to  the  field  new  systems  or  major  revisions,  (3)  system  maintenance,  and 
(4)  periodic  reevaluation  of  systems,  for  efficiency  and  effectiveness. 
MILPERCEN  is  identified  as  the  "Proponent  Agency",  which  is  apparently  based 
on  the  definition  appearing  in  the  recent  revision  of  AR  18-1.  That  definition 
is:  "The  element  assigned  responsibility  by  the  functional  proponent  for 
the  functional  design,  development,  implementation,  and  maintenance  of  an 


automated  system".  Annex  A  then  proceeds  to  indicate  that  SSC,  which  is 
implicitly  the  "Functional  Proponent",  is  to  be  responsible  for  the  Project 
Initiation  Phase,  the  Concept  Development  Phase,  and  the  Definition/Design 
Phase.  The  organization  directly  responsible  for  the  System  Development 
Phase  is  not  indicated.  Transfer  of  three  personnel  positions  from  MILPERCEN 
to  SSC  is  also  specified,  as  a  part  of  Annex  A.  Annex  B  of  this  MOU,  addresses 
the  function  titled  "Development  of  major  changes  to  standard  multicommand 
personnel  and  administration  information  system  (SIDPERS)".  Basically, 

Annex  B  states  that: 

"a.  MILPERCEN,  by  delegation  from  ODCSPER,  is  and  remains  the  Proponent 
Agency  (PA)  for  SIDPERS  and  is  responsible  for  performing  all  of 
the  functions  of  the  PA  as  outlined  in  AR  18-1  and  related  Army 
ADP  systems  policy  documents." 

"b  MILPERCEN  will  remain  responsible  for  receiving,  analyzing,  costing, 
and  managing  through  the  System  Change  Request  (SCR)  approval 
process  all  SCR  to  SIDPERS.  When  the  cost  of  implementing  a  given 
SCR  exceeds  $100,000,  responsibility  for  its  development  will  be 
transferred  through  ODCSPER  and  HQ,  TRAD0C,  to  SSC.  - " 

"c.  MILPERCEN  is  responsible  for  receiving  completed  system  changes 
and  associated  materiel  from  SSC,  incorporating  the  SCR  into  a 
System  Change  Package  (SCP),  transmitting  the  SRC  to  Computer 
Systems  Command  for  programming,  and  validating  the  SCR  as  part  of 
SCP  testing." 

Annex  B  identifies  SSC  as  responsible  for  "Developing  the  documentation 
necessary  to  incorporate  assigned  SCR  into  SIDPERS.  This  documentation  will 
include,  as  a  minimum,  changes  to  the  Detailed  Functional  System  Requirement 
(DFSR),  test  input  transactions  to  validate  the  change  and  required  user 
manual  changes." 

(d)  Regul atory/di recti ve  authori ti es .  Listed  below  are  those 
regulations  and  other  documents  which  prescribe  the  responsibilities 
and  govern  or  impact  upon  the  relevant  functions  at  the  Soldier  Support 
Center  in  the  area  of  PDSS. 

•  AR  10-5,  Organization  and  Functions  of  the  US  Army  1  November  1978 

•  AR  10-41,  Organization  and  Functions,  United  States  Army  Training 
and  Doctrine  Command,  27  June  1973 

•  TRAD0C  Regulation  10-41,  Organization  and  Functions,  1  May  1980 

•  AR  18-1,  Management  Information  Systems,  22  March  1976,  and  recent 
revision,  15  August,  1980 

•  AR  71-1,  Force  Development,  16  September  1968,  with  Change  1,  dtd 
25  June  1969 

•  MILPERCEN  Supplement  1  to  AR  10-5,  Organization  and  Functions, 

1  August  1979 

•  Memorandum  of  Understanding  Between  Deputy  Chief  of  Staff  for 
Personnel  and  Commander,  US  Army  Training  and  Doctrine  Command, 
and  Commander,  US  Army  Soldier  Support  Center,  signed  5-7  August 
1980 
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•  US  Army  Computer  Systems  Command,  Command  Fact  Sheet,  February  1979 

•  Department  of  the  Army,  Office  of  the  Assistant  Secretary,  Research, 
Development  and  Acquisition.  Memorandum  for  Deputy  Chief  of  Staff 
for  Research,  Development,  and  Acquisition,  Subject:  Standard¬ 
ization  of  Embedded  Computer  Resources,  1  July  1980 

•  Letter,  Office  of  the  Deputy  Commander,  TRADOC  Subject:  Standard¬ 
ization  of  Embedded  Computer  Resources,  30  July  1980 

•  AR  1000-1,  Basic  Policies  for  Systems  Acquisition,  1  April  1978 

•  AR  70-1,  Research  and  Development,  1  May  1975,  with  Change  1,  dtd 
1  February  1977,  and  revised  draft,  August  1980 

•  ADMINCEN  Regulation  10-1,  Organization  and  Functions, 

•  Charter,  Directorate  of  Doctrine  and  Combat  Development,  SSC 

•  HQDA  Ltr  18-80-1,  7  July  1980,  Subject:  Combat  Service  Support 
(CSS)  Automation/Communications  Transition  Plan,  from  DAAC-NIP(m) 

(20  Jun  80) ,  llpp 

•  DF,  DAPE-PBP,  16  August  1977,  Subject:  SIDPERS  System  Change 
Request  Procedures 

•  Memorandum  from  Assistant  Secretary  of  the  Army  for  Financial 
Management,  dated  28  August  1973,  Subject:  Standard  Installation/ 
Division  Personnel  System  (SIDPERS).  [This  represents  the  approved 
requirements  document  for  this  system.] 

(e)  Relationships  With  Users,  Materiel  Developers,  Training 
Developers.  Soldier  Support  Center  (SSC)  involvement  in  the  PDSS  process 
is  largely  in  its  early  stages.  Therefore,  PDSS  relationships  between  SSC 
and  Users,  Materiel  Developers,  Training  Developers,  and  others  involved 

in  PDSS  appear  to  be  evolving  rapidly.  The  Management  Information  Systems 
Division  (MISD)  of  SSC  has,  until  recently,  dealt  primarily  with  the  Field 
Military  Systems  Branch,  Field  Activities  Division,  of  MILPERCEN,  regarding 
requirements  and  related  aspects  of  SIDPERS  and  DLDED.  Interface  with  the 
System/Materiel  Developer  (Computer  Systems  Command)  had  been  primarily 
with  MILPERCEN.  Since  25  August  1980,  however,  as  a  result  of  the  MOU 
discussed  above,  SSC  liaison  people  have  been  located  at  MILPERCEN  and  are 
beginning  to  work  jointly  with  MILPERCEN  people  on  areas  such  as  the  esta¬ 
blishment  of  DLDED  personnel  software  specifications.  This  locational  change 
has  begun  to  bring  SSC  into  direct  contact  with  both  Computer  Systems  Command 
and  their  contractor  personnel.  Previously,  the  direct  interface  between 
MISD  and  SIDPERS  users  had  been  limited,  while  MILPERCEN's  Field  Military 
Systems  Branch  was  in  direct  contact  with  some  CTDPERS  users  on  almost  a 
daily  basis.  Again,  the  recent  MOU  will  place  SSC  personnel  in  more  direct 
contact  with  SIDPERS  users.  Relationships  between  MISD  and  Training  Developers 
apparently  are  not  formalized.  SIDPERS  training  aspects  have  been  addressed 
by  the  Procedures  and  Regulations  Review  Branch  of  MILPERCEN. 

(f)  Operating  Procedures.  Specific  operating  procedures  for 
PDSS  functions  at  Soldier  Support  Center  (SSC)  could  not  be  identified  during 
the  research  visit  to  SSC.  This  probably  reflects  the  early  stage  of  SSC 
involvement  in  PDSS  functions  and  also  the  fact  that  support  of  SIDPERS,  the 
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principal,  fielded  personnel  system,  has  been  provided  by  MILPERCEN.  Some 
aspects  of  procedures  followed  at  MILPERCEN,  however,  were  obtained  by 
questionnaire.  The  recent  MOU  between  MILPERCEN,  OCSPER,  SSC,  and  TRADOC 
identifies  some  basic  policies  and  procedures,  as  noted  above,  in  Paragraph 
(c)  under  Responsibilities.  It  is  evident  that  MILPERCEN  has  followed,  and 
intends  to  continue  to  follow,  procedures  "outlined  in  AR  18-1  and  related 
Army  ADP  systems  policy  documents,"  for  less  than  "major"  changes  to  SIDPERS. 
These  procedures  involve  a  System  Change  Request  (SCR)  proposal,  evaluation, 
approval,  and  implementation  process.  This  process  is  delineated  in  Section 
III  -  Change  Control,  of  Chapter  7  -  AMIS  Configuration  Management,  of  AR 
18-1,  22  March  1976,  and  the  more  recent  TB  18-110,  Configuration  Management. 
Specific  MILPERCEN  procedures  are  contained  in  DF,  DAPE-PBP,  16  August  1977, 
Subject:  SIDPERS  System  Change  Request  Procedures.  Annex  B  of  the  MOU 
defines  a  "major"  change  as  one  in  which  "the  cost  of  implementing  a  given 
SCR  exceeds  $100,000  — ".  This  threshold  is  based  on  Paragraph  2- 1 5 k  of 
AR  18-r  which  states,  "System  modifications  which  are  estimated  to  cost 
more  than  $100,000  will  follow  the  life  cycle  process,  starting  with  the 
MENS."  The  MOU  also  states  that  MILPERCEN,  in  arriving  at  the  estimated 
cost  of  a  given  SCR,  will  include  the  following  factors: 

"(1)  Costs  incurred  in  evaluating  the  SCR,  developing  the  required 

Systems  Change  Directive  (SCD),  and  staffing  and  controlling  the 
SCD. " 

"(2)  Costs  incurred  in  designing  and  developing  the  system  documenta¬ 
tion  required  to  incorporate  the  SCR  into  the  system  and 
developing  test  data  to  validate  it." 

"(3)  All  costs  incurred  in  programming  and  testing  the  SCR,  including 
necessary  computer  time." 

As  has  been  noted,  when  estimated  cost  of  a  given  SCR  exceeds  the  $100,000 
threshold,  responsibility  for  its  development  is  to  be  transferred  to  SSC. 
Although  specific  PDSS  and  other  procedures  to  be  followed  by  SSC  in  such 
cases  are  not  known  to  have  been  specified  yet,  it  appears  reasonable  to 
expect  that  the  same  configuration  management  procedures  discussed  above 
(TB  18-110)  will  be  followed  here  also. 

(g)  Gaps  and  duplications  in  current  PDSS  process.  Within 
this  portion  of  the  BFA,  the  current  PDSS  process  at  SSC  is  not  sufficiently 
well-defined  to  lend  itself  to  identification  of  gaps  and  duplications 
within  the  PDSS  process  itself.  In  the  somewhat  broader  realm  cf  regulations, 
charters,  responsibilities,  and  definitions  immediately  surrounding  this  PDSS 
area,  however,  some  issues  or  problems  are  evident.  Many  of  these  issues 
have  the  potential  for  fundamental  impacts  on  the  PDSS  process.  Therefore, 
these  evident  issues  are  identified  and  addressed  individually  below. 

1_.  Apparent  overlap  between  TRADOC  and  MILPERCEN 
organization  and  function  regulations.  An  overlap  in  responsibilities  appears 
to  exist  between  those  assigned  to  Soldier  Support  Center  (SSC)  in  TRADOC 


4 

AR  18-1  of  15  August  1980  is  quoted  here.  The  MOU,  however,  quotes 
the  9  November  1979  draft  revision,  anc!  lacks  the  words,  "startinq  wit'1 
MENS". 
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Regulation  10-41,  1  May  1980,  and  those  stated  in  portions  of  MILPERCEN 
Supplement  1  to  AR  10-5,  of  1  August  1979.  The  TRADOC  Regulation  is 
essentially  an  elaboration  of  the  responsibilities  of  TRADOC  as  stated  in 
AR  10-41,  27  June  1973.  Elements  of  this  TRADOC  Regulation  are  quoted  in 
Paragraph  (c),  above.  In  particular,  the  CG,  SSC,  is  assigned  the  mission 
to: 

"Develop,  review,  and  evaluate  all  concepts  and  doctrine  pertaining 
to,  or  impacting  upon,  personnel  management  and  services,  administrative 
management  and  services,  financial  management  and  services,  and  related 
computer  based  information  systems." 

Also,  to: 

"Develop  and  coordinate  the  functional  design,  evaluation,  and  extension 
of  battlefield  administration  management  information  systems  applicable 
to  the  corps  level  and  below." 

The  August  1979  MILPERCEN  Supplement  1  to  AR  10-5  states  initially  (page  3) 
that: 

"The  mission  of  the  United  States  Army  Military  Personnel  Center  is 
to  execute  and  recommend  military  personnel  policies,  systems,  and 
programs;  to  develop  and  supervise  procedures  applicable  to  military 
personnel  management  and  development  and  those  directly  related 
support  services,  to  include  personnel  information  systems,  in  support 
of  the  soldier  and  the  chain  of  command." 

Page  11  of  that  Supplement  states  13  responsibilities  of  the  Automation 
Management  Office  (AMO),  which  is  part  of  the  MILPERCEN  Command  Group.  At 
least  several  of  these  responsibilities  appear  relevant  to  this  discussion, 
namely: 

"1.  Ensures  that  all  automation  system  planning  first  considers 

mobilization  and  wartime  operations  and  then  provides  necessary 
peacetime  management  data." 

"5.  Develops  the  MILPERCEN  Automation  Master  Plan  and  coordinates 
the  plan  with  other  personnel  family  agencies  and  ensures  it 
is  in  accord  with  0DCSPER  automation  plan." 

"10.  Provides  control  over  system  development  and  system  change 
requests  to  ensure  all  system  users  and  system  interfaces 
are  accommodated." 

"11.  Executes  the  0DCSPER  subdelegated  automation  functions  with 
signature  authority." 

Page  129  of  that  Supplement  states  that  the  Office  of  the  Chief,  Field 
Activities  Division,  of  MILPERCEN,  among  other  responsibilities, 

"1.  Serves  as  the  MILPERCEN  primary  P0C  for  coordination  between 
the  DA  Staff  and  field  activities  on  all  matters  pertaining 
to  personnel  services  and  support  systems." 

"a.  Exercises  proponent  responsibility  for  the  Standard  Installa¬ 
tion/Division  Personnel  System  (SIDPERS)  to  include  SIDPERS- 
Wartime  (SIDPERS-WT). " 

"b.  Supervises  the  development,  modification,  coordination, 

testing,  validation,  and  publication  of  the  Military  Personnel 
Office  (MILP0)  and  SIDPERS  Interface  Branch  (SIB)  procedures 
and  systems  changes  which  support  policies,  programs,  and 
systems." 
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2.  Apparent  overlap  or  conflict  between  TRADOC  Regula¬ 
tion  10-41  and  the  5-7  August  MOU  with  MILPERCEN.  An  apparent  overlap  in 
responsibilities  also  appears  to  exist  between  those  of  TRADOC,  as  quoted 
from  TRADOC  Regulation  10-41  in  the  prior  paragraph,  and  those  delineated 
for  MILPERCEN  in  both  Annexes  A  and  B  of  the  MOU  signed  5-7  August  1980 
among  DCSPER,  MILPERCEN,  SSC,  and  TRADOC.  Portions  of  those  two  annexes 
were  quoted  in  Paragraph  (c),  above,  and  therefore  will  not  be  repeated 
here. 


3.  New  and  varying  definitions  concerning  proponency. 
Figure  2-10  contains  six  different  definitions  of  terms  containing  the  word 
"proponent".  In  particular,  it  can  be  seen  that  AR  18-1,  as  published 
15  August. 1980,  defines  both  "proponent  agency",  and  "functional  proponent". 
The  definition  of  the  former  is  substantially  different  from  the  1976 
definition.  Also,  the  term  "functional  proponent"  did  not  appear  earlier 
and  is  evidently  new.  Evidence  suggests  that  misunderstandings  as  to  the 
definitions  being  used  among  the  various  parties  may  be  contributing 
significant  confusion  to  the  reaching  of  a  cormion  view  of  the  responsibilities 
involved. 


4.  Split  responsibility.  The  current  MOU  between  DCSPER, 
MILPERCEN,  SSC,  and  TRADOC,  in  its  Annexes  A  and  B,  clearly  leaves  a  division 
of  responsibilities  between  SSC  and  MILPERCEN  for  both  SIDPERS  and  future 
personnel  and  administation  information  systems.  Such  divided  responsibilities, 
if  they  are  to  be  exercised  with  full  effectiveness,  would  appear  to  demand 
a  level  of  cooperation  and  coordination  which  may  be  difficult  to  sustain  or 
ensure  without  considerable  effort,  executive  attention,  and  possibly  further 
formalization.  It  should  be  noted  that  the  MOU  calls  for  establishment  at 
MILPERCEN  of  a  deputy  of  the  SSC  Commander. 

5_.  Fuzziness  of  "battlefield"  vs.  "non-battlefield" 
automated  systems.  In  this  portion  of  the  BFA,  significant  difficulty  is 
encountered  in  clearly  distinguishing  "battlefield"  from  "non-battlefield" 
automated  systems.  This  issue  arises  because  the  scope  of  this  study  effort 
specified  addressal  of  battlefield  automated  systems  (BAS).  Of  the  12  BAS 
identified  in  Table  5-4  of  the  PDSS  Concept  Plan  and  which  could  be  associated 
with  this  BFA,  all  but  DSU/GSU  and  TASC  are  either  encompassed  or  specifically 
addressed  in  Paragraph  (a),  above.  DSU/GSU  is  purely  logistical  in  appli¬ 
cation,  and  the  Theater  ADP  Service  Center  (TASC)  no  longer  needs  to  be 
addressed.  The  original  TASC  concept  was  for  major,  mainframe  hardware  to 
be  located  at  such  centers.  The  recent  CSS  Transition  Plan,  however,  has 
directed  that  the  functions  of  those  projected  centers  will  be  accomplished 
with  assemblages  of  DAS3  equipment.  (TAMMIS  includes  MEDL0G,  MEDBL00D, 

MEDREG,  and  MEDPAR.)  However,  several  systems  not  in  Table  5-4  are  identified 
in  Paragraph  (a)  above,  for  the  reasons  cited  there.  Further,  it  is  possible 
that  other  systems  could  be  included,  depending  on  one's  interpretation  of 
the  definition  of  BAS  and  the  purpose  of  the  study. 
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Assigned  Responsible  Agency  (ARA).  The  organizational  element 
designated  by  HQDA  to  be  responsible  for  the  development, 
test,  and  maintenance  of  a  standard  ADP  system.  This 
assignment  of  responsibility  includes  a  requirement  for 
coordination  with  users,  MACOM(s)  (if  applicable),  the  PA, 
and  HQDA  during  all  phases  of  development.  The  designation 
of  the  ARA  will  vary  depending  upon  the  type  of  system 
being  developed,  e.g.,  multicommand  or  command-unique 
systems.  The  ARA  for  Class  A-l  systems  will  normally  be 
USACSC.  (AR  18-1,  22  March  1976.) 

Assigned  responsible  agency  (ARA).  The  organizational  element 
designated  as  responsible  for  the  design,  configuration 
management,  development,  test,  deployment,  and  maintenance 
of  a  standard  ADP  system.  (AR  18-1,  15  August  1980) 

Functional  proponent.  The  Army  Staff  agency  responsible  for  the 
subject  area  in  which  automation  is  used  or  is  to  be  used, 
including  automation  in  support  of  the  function  performed. 

(AR  18-1 ,  15  August  1980.) 

Proponent  Agency  (PA).  The  organization/agency  with 

responsibility  for  the  particular  function(s)  which  a 
management  information  system  automates.  (AR  18-1, 

22  March  1976.) 

Proponent  agency  (PA).  The  element  assigned  responsibility  by 
the  functional  proponent  for  the  functional  design,  develop¬ 
ment,  implementation,  and  maintenance  of  an  automated  system. 
(AR  18-1,  15  August  1980.) 

Proponent.  A  TRADOC  organization,  normally  a  school,  which  has 
been  assigned  primary  responsibility  for  combat  development 
functions  relating  to  a  new  materiel  item  in  its  area  of 
interest.  (TRADOC  REG  600-4,  1  June  1978.) 

Proponent  (proponency) .  An  organization  or  staff  charged  with  the 
responsibility  for  coordinating  the  accomplishment  of  a 
material  or  subject  matter  task  in  its  area  of  interest. 
(TRADOC  REG  10-41,  1  May  1980.) 

Proponent.  An  Army  oraanization  or  staff  which  has  been  assigned 
primary  responsibility  for  materiel  or  subject  matter  in  its 
area  of  interest  (i.e.,  proponent  school,  proponent  staff 
agency,  proponent  center,  etc.).  (TRADOC  REG  71-9, 

1  October  1978  and  AR  71-3,  8  March  1977.) 


Figure  2-10.  Varying  definitions 
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6.  PDSS  required  in  a  crisis/combat  environment  not 
specified  for  SIDPERS.  It  has  been  indicated  by  MILPERCEN  that  a  specifica¬ 
tion  does  not  exist  for  the  software  support  required  in  a  crisis/combat 
environment,  including  target  response  times  for  both  interim  and  permanent 
corrections  of  urgent  operational  deficiencies. 

g.  Maneuver  BFA. 

(1)  BAS  addressed  in  this  BFA.  There  is  only  one  BAS,  the  Advanced 
Attack  Helicopter,  a  Category  2  system,  to  be  addressed  in  the  Maneuver  BFA.  It 
should  be  noted  that  a  portion  of  SIGMA  and  PLRS  are  also  intended  to  support  this 
BFA;  however,  they  are  addressed  in  this  report  under  the  Force  Level  Control  and 
Communications  Functional  Areas,  respectively,  where  proponency  is  assigned  ano 
where  the  impact  for  PDSS  resources  will  occur.  There  are  several  additional 
Category  3  systems  in  this  BFA,  under  proponency  of  the  Combined  Arms  Center  or 
the  US  Army  Aviation  Center,  but  the  focus  of  the  study  effort  is  defined  to  be 
primarily  on  Category  1  and  2  systems. 

(2)  Organizational  elements  involved  in  planning  for  and  providing 
PDSS.  The  US  Army  Aviation  Center  (USAAC),  Fort  Rucker,  Alabama,  is  the  Combat 
Developer  proponent  for  the  Advanced  Attack  Helicopter  (AAH).  Development  is 
being  accomplished  under  the  Program  Manager,  Advanced  Attack  Helicopter,  Saint 
Louis,  Missouri.  The  PDSS  Concept  Plan  for  BAS,  May  1980,  identified  the  AAH 

as  a  system  for  which  a  DARCOM  PDSS  Center  is  not  required  or  for  which  the  need 
has  not  been  determined.  Further  coordinated  action  between  the  CD  and  MD  is 
needed  with  respect  to  the  future  designation  of  a  PDSS  Center  for  supporting 
this  system. 

h.  Communications  Functional  Area. 

The  communications  functional  area  provides  the  mechanism  by  which 
the  commander  controls  all  other  battlefield  functions  in  the  performance  of  his 
mission.  The  focal  point  for  activities  in  this  functional  area  is  the  US  Army 
Signal  Center  (USASC)  at  Fort  Gordon,  Georgia. 

(1 )  BAS  addressed  within  this  BFA. 

The  Category  1  and  2  systems  which  are  addressed  within  the 
communications  functional  area  are  as  follows: 

(a)  Position  Location  Reporting  System  (PLRS).  The  function  of 
this  system  is  to  support  command  and  control;  however,  it  is  discussed  under  the 
Communications  Functional  Area  since  USASC  is  the  combat  development  proponent. 
This  system's  life  cycle  status  is  Full  Scale  Development  with  an  expected  IOC  of 
2nd  Quarter,  Fiscal  Year  84  (2QFY84).  The  proponent  is  USASC  and  the  developing 
command  is  CORADCOM.  Category  is  2B. 

( b )  Joint  Tactical  Information  Distribution  System  (JTIDS) . 

This  system  is  in  Full  Scale  Development  with  an  expected  IOC  of  2QFY82.  JTIDS 
is  a  joint  program  with  the  Air  Force  and  Navy,  pursuing  alternative  concepts. 
Materiel  development  is  managed  by  Joint  Program  Office  at  Hasscom  AFB.  Category 
is  2B. 
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(c)  Position  Location  Reporting  System/Joint  Tactical 
Information  Distribution  System  ( PLRS/JTIDS)  Hybrid.  The  PLRS/JTIDS Hybrid 
combines  desirable  features  of  both  the  PLRS  and  the  JTIDS  systems  into  a 
realtime  data  communications  system.  It  is  in  the  Validation  Phase  with  a 
target  IOC  of  1985  expected  through  a  five-phase  evolutionary  development 
plan.  The  proponent  is  USASC  and  the  developing  command  is  CORADCOM. 
Category  is  1. 


(d)  Division  Level  Data  Entry  Device  (DLDED).  The  DLDED  is 
in  the  conceptual  phase  with  a  target  IOC  of  4th  Qtr  FY  82-lst  Qtr  FY  83. 

The  proponent  is  USASC  and  the  developing  command  is  USACSC.  Category  is  2B. 


(e)  Joint  Tactical  Communications  (TRI-TAC)  Program.  The 
TRI-TAC  Program  is  a  joint  effort  by  the  USA,  USAF,  USN,  USMC,  DCA  and  NCA 
to  design,  develop,  and  acquire  switched  tactical  communications  systems. 

Of  the  system  components  currently  defined,  the  US  Army  has  proponency  for 
nine  of  them.  Of  those  nine,  four  fall  into  PDSS  category  2B  and  are  listed 
below. 


1_.  Automatic  Telephone  Central  Office  AN/TTC-39.  This 
system  is  in  production  with  an  expected  IOC  of  July  1983.  The  proponent  is 
USASC  and  the  developing  command  is  CORADCOM. 

2_.  Automatic  Message  Switching  Central  AN/TYC-39. 

This  system  is  in  production  with  an  expected  IOC  of  June  1983.  The  proponent 
is  USASC  and  the  developing  command  is  CORADCOM. 

2-  Communications  Terminal  AN/UGC-74A(V)3.  This 
system  is  in  full  scale  production.  IOC  was  December  1979.  The  pro¬ 
ponent  is  USASC  and  the  developing  command  is  CORADCOM. 

4.  Communications  Nodal  Control  Element  AN/TSQ- I I I (V) . 
This  system  is  in  full  scale  development  with  an  expected  IOC  of  1984. 

The  proponent  is  USASC  and  the  developing  command  is  ESD  AFSC. 

(f)  Automatic  Telephone  Central  Office  AN/TTC-38.  The 
AN/TTC-38  is  fully  operational,  but  will  be  replaced  by  the  AN/TTC-39 
as  soon  as  it  is  ready.  Therefore  PDSS  for  this  system  will  be  of  a 
short  duration.  The  proponent  is  USASC  and  the  developing  command  is 
CORADCOM.  Category  is  2B. 

(g)  Transportable  Automatic  Digital  Switch  (TADS) 

AN/MYQ-2.  The  TADS  was  produced  in  a  very  limited  quantity  and  is  being 
phased  out  in  June  1981.  Therefore,  it  will  not  be  considered  further 
in  this  study.  Category  is  2B. 
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(h)  Test  and  Automatic  Repair  Facility  AN/MSM-105  ( V ) 1 , 2 . 

The  AN/MSM-105  is  an  expanded  and  upgraded  version  of  the  AN/USM-410. 

It  has  an  expected  OT  III  date  of  1982.  The  proponent  is  USASC  and 
the  developing  command  is  CORADCOM.  Category  is  1. 

(2)  Organizational  elements  involved  in  planning  for  and 
providing  PDSS.  For  the  BAS  listed  above,  there  are  currently  ten  tiaj or 
organizational  elements  (with  various  subelements)  which  are  involved  in 
planning  for  and  providing  PDSS.  These  organizational  elements  are  listed 
below  and  their  PDSS  functions  are  described  in  Paragraphs  2-4. h. (3)  through 
2-4. h. (6). 


•  The  TRADOC  System  Manager  (TSM)  for  Army  Data  Distribution 
System  and  Mobile  Subscriber  Equipment  (ADDS/MSE) 

•  The  TRADOC  System  Manager  (TSM)  for  Army  Tactical 
Communication  Systems  (ATACS) 

•  The  TRADOC  System  Manager  (TSM)  for  Tactical  Automatic 
Switch  (TAC  AU  SW) 

•  The  TRADOC  System  Manager  (TSM)  for  Tactical  Satellite 
Communications  (TACSATCOM) 

•  The  TRADOC  System  Manager  (TSM)  for  Test  Measurement 
Diagnostic  Systems  (TMDS) 

•  The  Concepts  and  Studies  Division  (C&S),  Directorate  of 
Combat  Developments  (DCD),  USASC 

•  Officers  Department  (OFF-DEPT),  Directorate  of  Training 
(DT),  USASC 

•  Communications-Electronics  (C-E)  Board,  USASC 

•  Tactical  Data  Systems  Office,  Directorate  of  Training 
Developments  (DTD),  USASC 

•  Joint  Tactical  Communications  (TRI-TAC)  Office. 

(3)  Responsibilities/charters. 

(a)  The  mission,  authority,  and  responsibilities  of  the 
TSM-ADDS/MSE  are  spelled  out  in  the  TRADOC  System  Manager  Charter,  Army  Data 
Distribution  System  and  Mobile  Subscribe"  Equipment  (ADDS/MSE),  dated  16 
November  1979.  By  this  charter,  his  mission  is  to  conduct  total  system 
management  for  ADDS  and  MSE  within  TRADOC. 

Acting  under  this  charter,  the  TSM-ADDS/MSE  is  currently 
providing  User  representation  for  the  PLRS,  JTIDS,  and  PLRS/JTIDS  Hybrid 
systems  which  were  listed  in  Paragraph  2-4. h. ( 1 ) .  In  terms  of  PDSS,  this 
TSM  will  be  responsible  for  identifying  and/or  communicating  doctrinal  changes 
which  necessitate  enhancements  in  the  system  or  which  may  represent  a  new 
requirement  thereby  requiring  major  software,  firmware,  or  hardware  changes. 
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(b)  The  mission,  authority,  and  responsibilities  of  the 
TSM-ATACS  are  spelled  out  in  a  TSM  Charter  dated  June  1978.  By  this 
Charter,  his  mission  is  to  conduct  total  system  management  for  Army 
Tactical  Communication  Systems  (ATACS)  within  TRADOC. 

Acting  under  this  charter,  the  TSM-ATACS  is  currently 
providing  User  representation  for  the  AN/TTC-38  and  the  AN/UGC-74A(V)3 
which  were  listed  in  Paragraph  2-4.h.(l).  For  these  systems,  TSM-ATACS  and 
is  ensuring  that  User  requirements  are  being  satisfied  in  terms  of  0&0 
concepts,  hardware,  software,  training,  fielding,  and  ILS  support. 

(c)  The  TSM-TAC  AU  SW,  operating  under  a  TSM  Charter,  is 
conducting  total  system  management  within  TRADOC  for  Tactical  Automatic 
Switches  (TAC  AU  SW).  Of  the  systems  listed  in  Paragraph  2—4. h. (1 ) ,  he 

is  providing  User  representation  for  the  AN/TTC-39,  the  AN/TYC-39,  and  the 
AN/TSQ-111 (V). 


(d)  The  TSM-TACSATCOM,  operating  under  a  TSM  Charter 
dated  10  September  1978,  is  conducting  total  system  management  within 
TRADOC  for  Tactical  Satellite  Communications  (TACSATCOM).  All  of  the 
systems  for  which  he  currently  is  providing  User  representation  are 
Category  3.  They  are  not  listed  in  Paragraph  2-4.h.(l),  but  are  listed 
in  Appendix  C. 

(e)  The  TSM-TMDS  was  recently  designated  and  does  not 
yet  have  a  formal  charter  from  TRADOC  although  a  draft  charter  has  been 
approved.  TSM-TMDS  will  conduct  total  system  management  within  TRADOC 

for  Test  Measurement  Diagnostic  Systems  (TMDS).  The  systems  from  Paragraph 
2-4 . h . (1 )  for  which  he  is  providing  User  representation  are  the  DLDED  DS/ 
ATSS  and  the  AN/MSM-105(V)1 ,2. 

(f)  The  functions  of  the  Concepts  and  Studies  Division 
(C&S),  Directorate  of  Combat  Development,  USASC  are  delineated  in  USASIGS 
Regulation  10-2.  Among  its  many  functions,  those  which  may  impact  upon 
PDSS  are  as  follows: 

•  Provides  input  to  general  functional  systems  requirements 
and  detailed  systems  requirements  for  automated  communica¬ 
tions  control  systems 

•  Assists  in  determining  requirements  and  preparing  proposals 
for  force  development  testing  and  experimentation  and  reviewing 
results 

•  Prepares,  coordinates,  and  reviews  international  standardization 
agreements  within  assigned  area  of  proponency. 

•  Develops  maintenance  concepts  and  reviews  the  maintenance 
test  package 

t  Maintains  cognizance  of  computer  simulation  models  used  by 

communication  system  analyses  in  CE  system  design,  engineering, 
and  evaluation. 
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(g)  The  Communications-Electronics  (C-E)  Board  at  Fort 
Gordon  is  one  of  eight  US  Army  test  boards  and  as  such  is  assigned  the 
following  missions  under  TRADOC  Regulation  10-41: 

•  Plan,  conduct,  and  report  on  operational  and  other  user  tests 

•  Participate  in  other  testing  as  directed 

•  Provide  advice  and  guidance  on  test  matters  to  combat,  training, 
and  materiel  developers,  other  services  and  private  industry 

•  Conduct  other  tests  and  selected  specific  evaluations  as  directed 
by  CG  TRADOC. 

(h)  The  TRI-TAC  Office  is  chartered  by  DOD  Directive  5148.7 
to  perform  the  following  responsibilities  and  functions: 

•  Coordinate  and  provide  management  direction  for  the  development 
and  production  of  TRI-TAC  systems  and  equipment  including 
logistics  support  considerations  in  response  to  Military 
Services  and  Joint  requirements 

•  Perform  system  definition  and  engineering  of  the  TRI-TAC  systems 

and  equipment.  3 

•  Provide  advice  and  assistance  to  the  ASD  (CJI),  the  JCS,  the 
MILDEPS  and  Defense  Agencies  concerned  with  developing  and 
implementing  plans  and  programs  for  TRI-TAC 

•  Ensure  the  adequate  conduct,  planning  and  reporting  of  joint 
testing,  except  for  follow-on  OT&E,  of  TRI-TAC  systems  and 
equipment. 

(4)  Regulatory/di recti ve  authorities.  Listed  below  are  the 
regulations  and  other  documents  which  prescribe  the  responsibilities  for  and 
govern  or  impact  upon  PDSS  functions  in  the  communications  functional  area. 

•  AR  10-5:  Organization  &  Functions  of  the  US  Army, 

1  November  1978 

•  AR  10-41:  Organization  &  Functions,  United  States  Army 
Training  and  Doctrine  Command,  27  June  1973 

•  TRADOC  Regulation  10-41:  Organization  and  Functions, 

1  May  1980 

•  USASIGS  Regulation  10-2:  Organization  and  Functions  Manual, 

May  1977 

•  Pamphlet  11-25:  Life  Cycle  System  Management  Model  for 
Army  Systems,  21  May  1975 

•  Department  of  Defense  Directive  5000.1:  Major  System 
Acquisitions,  19  March  1980 

•  Department  of  Defense  Directive  5000.2:  Major  System 
Acquisition  Procedures,  19  March  1980 

•  Department  of  Defense  Directive  5000.3:  Test  and 
Evaluation,  26  December  1979 

•  TRADOC  Regulation  71-12:  Total  System  Management- 
TRAD0C  System  Manager  (TSM),  15  September  1978 
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(5)  Relationships  with  Users,  Materiel  Developers,  Training 
Developers.  The  TSM  Charters,  under  which  the  TSMs  at  USASC  operate, 
specify  that  the  TSMs  are  authorized  to  coordinate  directly  with  the 
following  organizations  on  matters  related  to  the  systems  for  which  they 
are  responsible: 

t  HQDA 

•  HQ  TRADOC 

•  USA  DARCOM,  PM  &  Major  Subordinate  Commands 

•  USAOTEA 

•  USAMACOM  (USAFORSCOM,  USAREUR,  Eighth  US  Army) 

•  CDRMILPERCEN 

•  Other  Military  Services,  agencies,  and  organizations  as 

required. 

Operating  under  these  guidelines,  the  following  working  relationships  have 
been  established: 

(a)  TSM-ADDS/MSE  interacts  weekly  with  CORADCOM  PM-PLRS/TIDS 
on  user  needs  and  their  impact  on  system  design. 

(b)  TSM-ADDS/MSE  interacts  weekly  with  TRADOC  proponent 
schools  on  user  needs. 


(c)  TSM-ATACS 
PIPS,  and  coordination. 

(d)  TSM-ATACS 

and  PIPS. 

(e)  TSM-ATACS 


interacts  as  required  with  HQDA  on  requirements, 
interacts  daily  with  PM-ATACS  on  coordination 
interacts  daily  with  DCD,  USASC  on  tasking  and 


coordination. 

(f)  TSM-ATACS  interacts  weekly  with  DOT  and  DTD,  USASC  on 
tasking  and  coordination. 

(g)  TSM-ATACS  interacts  bi-weekly  with  C-E  Test  Board  on 
testing  and  coordination. 

(h)  TSM-TAC  AU  SW  interacts  weekly  with  HQDA  on  equipment 
production  requirements. 

(i)  TSM-TAC  AU  SW  interacts  monthly  with  TRI-TAC  on 
testing,  requirements,  and  system  architecture. 

(j)  TSM-TAC  AU  SW  interacts  weekly  with  CORADCOM  PM-MSCS  on 
testing  and  system  requirements. 
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(k)  TSM-TMDS  interacts  quarterly  with  all  USAMACQM  on  fielding. 

(l)  TSM-TMDS  interacts  daily  with  all  TRADOC  proponents 
on  fielding,  training,  software  requirements,  and  specifications. 

(m)  TSM-TMDS  interacts  daily  with  HQDA  on  funding  and 

requirements. 

(n)  TSM-TMDS  interacts  daily  with  CSC  on  all  aspects  of 
system  development. 

(6)  Operating  procedures.  Since  the  majority  of  the  systems 
listed  in  Paragraph  2-47h . ( 1 )  have  not  yet  been  fielded,  PDSS  experience 
is  very  limited  and  no  formal  operating  procedures  are  in  use.  In  the 
past,  for  smaller  and  less  complicated  systems,  the  procedure  for 
correcting  software  errors  or  making  improvements  has  been  for  the  User 
to  submit  a  Product  Improvement  Proposal  (PIP)  and/or  a  new  Required 
Operational  Capability  (ROC)  to  the  Materiel  Developer.  However,  since 
the  processing  of  either  a  PIP  or  a  ROC  is  very  costly  and  time  consuming, 
this  approach  may  not  be  sufficient  for  the  larger  and  more  rapidly 
changing  systems. 

A  PDSS  plan  for  the  AN/TTC-39  and  AN/TYC-39  systems  has 
been  prepared  and  is  being  finalized.  This  plan  provides  for  the  creation 
of  a  Software  Support  Center  to  handle  all  software  maintenance  and 
provides  for  the  use  of  the  TRI-TAC  Joint  Test  Facility  for  testing  the 
modified  software. 

(7)  Gaps  and  duplications  in  current  PDSS  processes.  The  major 
gap  which  exists  in  PDSS  for  the  communications  functional  area  is  that  for 
most  systems  PDSS  has  not  yet  been  addressed  since  the  fielding  dates  are 
several  years  into  the  future. 


s 

i 
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CHAPTER  3 


TRADOC  PDSS  REQUIREMENTS 


3-1.  GENERAL. 

a.  Requirements  Addressed.  This  chapter  documents  the  results  of  the 
research  and  analysis  conducted  during  performance  of  Task  4  of  the  study. 

Task  4  was  directed  toward  identifying  and  describing  the  BFA-level  PDSS 
requirements  of  TRADOC  Centers  and  Schools.  HQ  TRADOC  requirements  were  also 
addressed.  In  accomplishing  this  task,  the  Study  Team's  effort  focused 
initially  on  identifying  the  Combat  Developers  PDSS-related  functional  re¬ 
sponsibilities  and  then  on  addressing  the  resource  requirements  associated 
with  these  functions.  The  resource  requirements  set  forth  for  each  BFA  are 
those  perceived  by  TRADOC  personnel  who  were  contacted  during  visits  to  the 
various  Schools  and  Centers.  The  scope  of  the  Phase  I  effort  did  not  provide 
for  study  team  validation  or  analysis  of  these  stated  resource  requirements. 
They  will  be  considered,  however,  in  the  development  of  alternative  structures 
during  Phase  II  and  justification  for  these  resource  requirements  identified 
within  each  alternative  structure  will  be  provided  in  the  Phase  II  technical 
report. 

b.  Basis  for  Requirements.  The  PDSS-related  functional  responsibilities 
identified  during  this  effort,  and  discussed  below,  derive  primarily  from 
TRADOC' s  basic  responsibilities  as  set  forth  in  AR  10-41:  Organization  and 
Functions,  US  Army  Training  and  Doctrine  Command,  which  are  expanded  upon 

in  other  applicable  Army  and  TRADOC  regulatory  documents  discussed  in  Chapter 
2.  Within  the  scope  of  TRADOC's  regulatory  responsibilities,  specific  PDSS 
functional  requirements  were  then  identified.  In  structuring  this  set  of 
PDSS  functional  requirements,  the  Study  Team  drew  upon  the  minimum  set  of 
tasks  necessary  for  PDSS  which  were  formulated  by  the  PDSS  Task  Force  involved 
in  the  DARCOM- initiated  PDSS  study  and  documented  in  the  PDSS  Concept  Plan 
for  BAS,  May  1980.  This  minimum  set  of  tasks  necessary  for  PDSS  is  discussed 
further  in  Paragraph  3-3. 

3-2.  TRADOC  PDSS  ROLE.  TRADOC,  as  the  Army’s  principal  Combat  Developer, 
has  a  critical  and  increasing  role  in  the  development  and  life  cycle  manage¬ 
ment  and  support  processes  for  battlefield  automated  systems.  There  are 
several  reasons  for  the  increase  in  this  role  but  the  driving  factors  are: 

9  The  growing  trend  toward  embedding  more  doctrine,  tactics,  and 
functional  procedures  in  BAS  software,  thus  necessitating  more 
direct  CD  participation  in  analysis  and  decisions  pertaining  to 
system  changes  that  could  affect  any  of  these  areas, 

•  The  growing  number  of  BAS  being  fielded  which  makes  definition  and 
maintenance  of  functional  interoperability  requirements  more 
complex,  and 

•  The  continually  evolving  nature  of  some  BAS  which  is  now  an  accepted 
system  development  approach  per  DODI  5000.2,  but  which  has  major 
implications  for  System  and  Combat  Developers,  Users,  and  all  system 
support  activities. 
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Fulfillment  of  this  increased  role  in  POSS  for  BAS  imposes  additional 
functional  requirements  on  HQ  TRADOC  and  all  TRADOC  Centers  and  Schools 
involved  in  supporting  battlefield  systems.  While  most  of  these  functional 
requirements  are  common  to  all  Centers  and  Schools,  their  magnitude  varies 
among  the  TRADOC  organizations.  There  are  also  some  unique  requirements  that 
must  be  considered.  These  PDSS  functional  requirements  and  the  associated 
resources  needed  to  effectively  accomplish  the  PDSS  functions  that  are 
identified  are  discussed  in  the  paragraphs  that  follow. 

3-3.  COMMON  PDSS  FUNCTIONAL  REQUIREMENTS. 

a.  Combat  Developer  Functions.  TRADOC  is  the  battlefield  architect 
responsible  for  determining  what  capability  is  required  and  when  it  is 
required.  TRADOC  responsibilities  encompass  those  of  Combat  Developer, 
Training  Developer,  and  User  Surrogate.  In  meeting  these  responsibilities, 
TRADOC  Centers  and  Schools  must  routinely  perform  a  number  of  functions  that 
relate  to  the  development,  training,  fielding,  and  maintenance  of  battlefield 
automated  systems.  These  functions  fall  generally  into  the  eight  functional 
areas  identified  and  briefly  described  in  Figure  3-1. 

b.  PDSS  Tasks. 

(1)  In  focusing  on  and  expanding  upon  the  third  functional  area 
shown  in  Figure  3-1,  Software  Maintenance  of  PDSS,  the  PDSS  Task  Force 
involved  with  developing  the  PDSS  Concept  Plan  for  BAS  formulated  the 
minimum  set  of  tasks  necessary  for  PDSS  referred  to  in  Paragraph  3.1,  above. 
These  tasks,  which  were  grouped  into  six  functional  areas--Management, 
Analysis,  Modification,  Test,  Field  Support,  and  Other--are  presented  in 
Figure  3-2.  Review  of  these  tasks  indicates  that  they  extend  into  both  the 
Materiel  Developer  and  Combat  Developer  areas  of  responsibility. 

(2)  Analysis  of  this  set  of  minimum  PDSS  tasks,  TRADOC' s  basic 
regulatory  responsibilities,  and  the  role  of  TRADOC  in  PDSS  provides  a  basis 
for  formulating  a  set  of  PDSS  functional  requirements  common  to  all  TRADOC 
Centers  and  Schools  involved  with  PDSS  for  BAS.  These  functional  requirements 
are  presented  in  Figure  3-3,  grouped  into  the  same  six  functional  task  areas 
as  shown  in  Figure  3-2. 

c.  Relationship  of  PDSS  Tasks  and  Combat  Developer  Functions. 

(1)  The  close  relationship  and  dependency  between  these  common 
PDSS  functional  requirements  and  the  other  Combat  Developer  functions  shown 
in  Figure  3-1  are  readily  apparent.  Most  of  the  PDSS  functions  can  be  viewed 
as  processes  or  elements  within  one  or  more  of  the  other  seven  functional 
areas.  They  should  be  addressed  and  accomplished  as  integral  parts  of  the 
other  functional  areas  where  appropriate. 


FUNCTIONS  OF  TRADQC  CENTERS  AND  SCHOOLS  RELATED  TO 
AUTOMATED  SYSTEMS  DEVELOPMENT,  TRAINING,  MAINTENANCE  AND  FIELDING 


1.  Research  and  Analysis:  Functions  in  this  area  include  development 
and  evaluation  of  new  concepts,  threat  impact,  interoperability,  force 
structure,  tactics,  doctrine,  operating  procedures,  logistic  and  mainte¬ 
nance  concepts,  technology  and  other  areas  that  relate  to  the  employment 
of  automation  on  the  battlefield. 

2.  Development  of  System  and  Software  Requirements:  This  area  in¬ 
cludes  the  definition  of  requirements,  at  both  the  system  and  the  software 
(tactical)  levels  ensuring  that  they  are  valid,  complete,  consistent  and 

in  consonance  with  the  mission(s),  doctrine,  tactics,  operating  procedures, 
and  interoperability  requirements  they  implement. 

3.  Software  Maintenance  (also  called  PDSS) :  This  functional  area 
includes  evaluation  of  trouble  reports  from  users;  evaluation  of  proposed 
changes;  identification  of  system  changes  required  due  to  changes  in 
threat,  mission,  doctrine,  tactics,  or  operational  procedures;  and 
ensuring  that  interoperability  requirements  are  met  and  maintained.  It 
also  includes  establishing  priority  schemes  for  fixes/changes  to  be 
applied  to  existing  systems  to  provide  compatibility  and  interface  with 
associated  developmental  systems. 

4.  Training  Development:  Functions. in  this  area  involve  determining 
requirements  for  institutional  and  unit  training  (both  initial  and 
readiness/proficiency  maintenance,  for  instructors  and  system  operators) 
system  and  non-system  training  devices/simulators/simulations,  and 
scenarios  therefor,  and  for  determining  course  content,  standards  of 

of  performance,  programs,  procedures,  necessary  instructor  qualifications, 
and  training  literature.  All  of  the  above  must  be  addressed  at  the 
proper  time  in  the  system  development  or  system  change  cycle  to  insure 
that  all  changes  are  appropriately  reflected  in  all  training  media  at 
the  time  necessary  to  preserve/maintain  overall  systems  readiness/ 
effectiveness.  New  Equipment  Training  must  also  be  addressed  in  co¬ 
ordination  with  the  Materiel  Developer. 


Figure  3-1.  Functions  of  TRADOC  Centers  and  Schools  related  to 
development,  training,  maintenance,  and  fielding  of 
automated  systems  (continued  on  next  page) 


5.  Guidance  to  the  Field:  This  area  involves  functions  necessary  to 
ensure  that  the  User  receives  proper  guidance  to  operate,  maintain  and 
"fight"  the  system  in  its  field  environment,  especially  in  those  situa¬ 
tions  where  doctrinal  parameters  may  need  to  be  "tailored"  for  the  mis¬ 
sion,  theater,  situation  and  command  strategies;  also  to  properly 
orchestrate  the  delivery  of  this  guidance  and  feedback  under  conditions 
of  changes  in  threat,  mission,  doctrine,  system  software,  and  systems 
with  which  integration  is  essential. 

6.  Support  to  Contingency  Planning  and  Operations:  Emphasis  in  this 
area  is  on  developing  and  recommending  force  structure  and  mix,  command  and 
control  procedures,  communications  requirements  and  system  tailoring  for 
planned  or  postulated  missions  or  operations  in  current  or  contemplated 
theaters  of  employment.  System  tailoring  is  provided  through  set-up  of 
variable  software  parameters  to  optimize  system  performance  on  a  mission 
contingency  basis. 

7.  Systems  Testing:  Functions  in  this  area  involve  specifying 
system  change  test  conditions,  monitoring  development  testing,  partici¬ 
pating  in  operational  testing,  and  planning  and  conducting  or  monitoring 
User  acceptance  testing. 

8.  Support  of  Wartime/Crisis  Operations:  This  area  includes  partici¬ 
pation  in  planning  and  providing  support  to  Field  Users  during  crisis/ 
wartime  to  ensure  that  battlefield  systems  are  maintained  in  an  effective 
operational  condition,  capable  of  performing  as  intended  in  accordance 
with  user  requirements  and  that  "procedural  workarounds"  are  provided 
when  time  or  other  factors  do  not  permit  software  changes.  This  requires 
a  capability  to  respond  rapidly  to  User-reported  operational  system 
problems. 


Figure  3-1.  (concluded) 
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1 .  Management 

a.  Development  and  maintenance  of  a  software  sup¬ 
port  plan  responsive  to  user  requirements  as 
determined  by  the  user  representative  (for 
example,  TRADOC  center  or  school) 

b.  Planning,  acquisition,  and  maintenance  of 
resources 

c.  Operation  of  the  PDSS  centers/support  facilities 

d.  Configuration  management  of  the  sof t  ;are 
system. 

2.  Analysis 

a.  Analysis  of  a  system  to  determine  the  nature  of 
the  problem  —  whether  hardware,  software  or 
both 

b.  Analysis  of  software  problem  reports 

c.  Analysis  of  proposed  system  changes  to  deter¬ 
mine  technical,  operational,  resource,  and 
schedule  impacts 

d.  Analysis  of  support  software  changes  due  to 
hardware  variations 

e.  Determination  of  the  possible  impact  of  soft¬ 
ware  changes  on  hardware/software 

f.  Analysis  of  system  changes  due  to  interopera¬ 
bility  requirements. 

g.  Analysis  of  conceptual  changes  to  fielded 
systems,  such  as  doctrine,  tactics,  operating 
procedures,  command  and  control,  organizational 
concepts,  training,  and  logistics. 

3.  Modification 


a.  Development  of  system/softwa're  change 
requirements 

Figure  3-2.  Minimum  set  of  tasks  necessary  for  PDSS* 
_ _  _  _  (Continued  on  next  page) _  .  _ 

*  As  defined  in  the  PDSS  Concept  Plan  for  BAS,  May  1980 


b. 

Development,  design,  implementation,  and 
documentation  of  all  software  modifications 

c. 

Maintenance  of  documentation  necessary  to 
support  existing  software  and  development 
systems 

d. 

Distribution  of  changes  in  accordance  with 
the  Configuration  Management  Plan 

e. 

Compliance  with  approved  design  standards 

f. 

Compliance  with  approved  programming 
standards 

g. 

Compliance  with  approved  documentation 
standards 

4. 

Test 

a. 

Verification  and  validation  of  software 
and  system  changes 

b. 

Testing  and  evaluation  of  the  impact  of 
changes  on  the  operational  function 

c. 

User  acceptance  testing,  including  evalua¬ 
tion  of  operational  suitability  and  oper¬ 
ational  effectiveness. 

5. 

Field  Support 

a. 

Provision  of  field  support,  including 
development  and  guidance  to  the  field  on 
operation  and  employment  of  the  systems 

b. 

Maintenance  of  communication  and  procedures 
between  the  field  and  support  activity. 

6. 

Other 

a. 

Development  of  system  test  and  analysis 
software/hardware 

b. 

Development  and  maintenance  of  simulations 
and  emulations,  where  required 

Figure  3-2.  (continued) 
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c.  Development  and  conduct  of  the  training 
necessary  to  introduce  new  software  versions 
and  maintain  old  systems 

d.  Development  and  distribution  of  procedural , 
operational,  training,  and  maintenance 
documentation  and  special  operating  instruc¬ 
tions. 


Figure  3-2.  (concluded) 


TASK  AREA _ TRADOC  RESPONSIBILITY _ FUNCTIONS _ 

ANALYSIS  4.  ANALYZE  FUNCTIONAL  IMPACT  OF  1.  IDENTIFY  OPERATIONAL  IMPACT. 

(CONTINUED)  PROPOSED  SYSTEM  CHANGES.  2.  IDENTIFY  USER-RESOURCE  REQUIREMENT  IMPACT. 

3.  IDENTIFY  TRAINING  IMPACT. 
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THREAT,  DOCTRINE,  AND  OPERATIONAL  REQUIREMENTS. 


(2)  The  extent  to  which  the  common  PDSS  functional  requirements 
(Figure  3-3)  must  be  addressed  within  each  BFA,  additional  unique  functional 
requirements  of  the  Centers  and  Schools,  and  the  resultant  capability  and 
resource  requirements  generated,  are  discussed  in  Paragraph  3-5  below. 

3-4.  HQ  TRADOC  REQUIREMENTS. 

a.  Functions  to  be  Performed. 

(1)  HQ  TRADOC  must  be  cognizant  of  major  PDSS  activities  within 
the  command.  With  respect  to  these  activities,  the  HQ  TRADOC  role  is  one 

of  receiving  directions  or  requirements  from  Headquarters,  Department  of  the 
Army  or  requests  from  Users,  analyzing  and  translating  these  into  requirements 
or  instructions  for  subordinate  commands,  exercising  staff  supervision, 
reviewing  the  subsequent  activity,  and  acting  upon  the  products  of  the 
subordinate  commands. 

(2)  Within  HQ  TRADOC,  the  Deputy  Chief  of  Staff  for  Combat  develop¬ 
ments  (DCSCD)  has  primary  staff  responsibility  for  PDSS.  This  stems  from  his 
responsibility  for  monitoring  all  user  aspects  of  materiel  systems  throughout 
their  life  cycle  to  insure  integration  of  doctrine,  tactics,  training,  personnel, 
and  logistics  requirements.  Within  DCSCD,  coordinating  responsibility  for 

PDSS  is  assigned  to  the  Systems  Integration  Branch,  Telecommunications, 

Command  and  Control,  and  Computer  Systems  (TC4S)  Directorate.  Each  of  the 
"hardware  directorates"  (e.g..  Firepower  Systems,  Intel  &  EW,  and  Maneuver 
Systems)  within  DCSCD  has  HQ  TRADOC  staff  responsibility  for  PDSS  within  its 
associated  Center(s)  and  School (s).  Within  these  DCSCD  directorates, 
designated  staff  officers  are  responsible  for  exercising  this  responsibility 
for  one  or  more  systems  within  their  functional  area.  Among  these  director¬ 
ates,  the  Intelligence  and  EW  Directorate  plays  a  particularly  prominent  role 
with  respect  to  systems  in  the  Intel ligence/EW  BFA  because  of  the  relationships 
and  interaction  between  Intel  1 igence/EW  BAS  and  intelligence  systems  that 
operate  at  or  support  echelons  above  corps  (EAC)  and  strategic  levels.  The 
TC4S  Directorate  has  HQ  TRADOC  staff  responsibility  for  Combat  Service  Support 
(CSS)  and  Command  and  Control  (C  ;  systems. 

b.  Requirements.  An  element  is  needed  within  DCSCD  to  serve  as  the 
focal  point  for  PDSS  activities  and  to  actively  coordinate  all  PDSS  actions 
with  other  elements  involved  both  within  and  external  to  HQ  TRADOC.  While 
such  a  focal  point  has  been  designated,  as  stated  above,  staffing  of  that 
element  does  not  appear  to  be  adequate  to  handle  this  responsibility, 
particularly  as  PDSS  requirements  and  HQ  TRADOC 's  involvement  continue  to 
increase.  A  minimum  of  one  staff  officer  (military  or  civil  service) 

is  needed  to  handle  these  expanding  responsibilities  in  a  timely  and 
effective  manner. 


3-5.  FUNCTIONAL  AREA  REQUIREMENTS. 


a.  Force  Level  Control  Functional  Area. 

(1)  Systems  to  be  supported.  The  Force  Level  and  Maneuver  Control 
System  (SIGMA)  and  the  PLRS  are  the  only  BAS  projected  to  require  PDSS  support 
in  the  command  and  control  area  at  this  time.  PDSS  requirements  associated 
with  PLRS  are  discussed  in  more  detail  in  Paragraph  3-5. g.,  under  the  Communi¬ 
cations  BFA  since  the  US  Army  Signal  Center  is  the  system  proponent  and  the 
PDSS  resource  impact  will  be  greatest  in  that  area.  As  stated  in  Paragraph 

2- 4. b.,  current  plans  provide  for  this  system  to  be  developed  under  the  evolu¬ 
tionary  process  authorized  by  DODI  5000.2.  An  initial.  Phase  1  version  of 
this  system,  called  the  Operations  Control  and  Command  Information  System,  is 
to  be  deployed  to  USAREUR  beginning  in  October  1980,  in  accordance  with  the 
USAREUR  Implementation  Plan,  Phase  1,  12  June  1980.  PDSS  will  be  required  for 
this  Phase  1  version  of  the  system  following  its  deployment  as  shown  in  Figure 

3- 4.  Present  plans  provide  for  this  initial  Phase  1  system  to  be  expanded  and 
extended  in  USAREUR  and  to  other  US  Army  corps  and  divisions  in  an  evolutionary 
manner.  As  this  plan  is  implemented,  PDSS  requirements  will  increase  in  both 
magnitude  and  complexity.  Also,  PDSS  planning  for  the  objective  system  that 
ultimately  evolves  from  the  SIGMA  development  effort  must  begin  and  be  continued 
as  an  integral  part  of  system  development  as  it  proceeds. 

(2)  Functions  to  be  performed.  Basic  functions  to  be  performed  by 
the  CD  in  planning  for  and  providing  PDSS  to  SIGMA  are  those  identified  in 
Figure  3-3.  In  addition  to  these  basic  functions,  personnel  involved  with  PDSS 
for  SIGMA  will  also  be  responsible  for  insuring  the  integration  of  SIGMA  with 
other  control  systems  since  SIGMA  will  be  the  driver  of  CCS  .  Any  change  to 
another  control  system  must  be  coordinated  with  SIGMA  before  being  exported  to 
the  field  as  a  system  change  package  for  implementation.  Another  factor  to  be 
considered  is  that  the  evolutionary  process  through  which  SIGMA  is  to  be  develop 
ed  may  impose  increased  PDSS  requirements  as  development  progresses  from  one 
version  of  the  system  to  the  next.  Location  of  the  CORADCOM-managed  PDSS  Center 
for  SIGMA  at  Fort  Leavenworth  as  provided  in  the  PDSS  Concept  Plan  for  BAS,  May 
1980,  will  facilitate  coordination  and  interaction  between  the  CD  and  MD  organ¬ 
izations  involved  with  all  aspects  of  PDSS  for  this  system  as  it  evolves. 

(3)  Requirements. 

(a)  At  this  stage  of  the  SIGMA  development  effort,  CD  resources 
assigned  direct  responsibilities  for  the  program  (elements  of  the  Army  C  / 
JINTACCS  Division,  CJI  Directorate,  CACDA),  appear  to  be  adequate  to  handle  the 
initial  Combat  Developer  PDSS  planning  functions  for  this  system.  As  system 
development  progresses  under  the  evolutionary  concept  and  PDSS  requirements 
increase,  additional  resources  will  be  needed  to  fulfill  CD  responsibilities  in 
planning  for  and  providing  PDSS  for  this  system.  In  particular,  since  this 
system  must  interoperate  extensively  with  other  control  systems  (e.g.,  TACFIRE, 
ASAS,  etc.)  under  the  CCS^  Concept,  careful  attention  must  be  devoted  to  the 
impact  of  system  changes  on  interoperability  requirements. 
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(b)  Part  of  the  increased  resource  requirement  associated 
with  PDSS  for  SIGMA  could  be  satisfied  by  establishing/staffing  the  TSM 
SIGMA  Office  within  CACDA.  In  addition  to  the  normal  resources  of  the  TSM 
Office,  a  limited  number  of  system/software  oriented  personnel  will  be 
needed  to  carry  out  detailed  CD  PDSS  functions  to  include  interacting  as 
necessary  at  the  working  level  with  system  users  and  with  the  CORADCOM- 
managed  PDSS  Center  at  Fort  Leavenworth.  Specific  CD  resources  requirements 
have  not  been  identified  at  this  time.  They  are,  in  part,  dependent  upon 
future  plans  and  decisions  regarding  SIGMA  development  and  acquisition. 

b.  Fire  Support  BFA. 

(1)  Systems  to  be  supported.  Within  the  Fire  Support  BFA  there 
are  currently  three  systems  which  will  require  PDSS.  These  three  systems 
(TACFIRE,  BCS,  and  PERSHING  II)  were  described  in  Paragraph  2-4. c.  and  are 
itemized  in  Figure  3-5  with  an  indication  of  when  PDSS  will  be  required. 

(2)  Functions  to  be  performed.  Figure  3-3  presented  an  extensive 
list  of  TRADOC  PDSS  responsibilities  and  functions.  For  the  Fire  Support 
BFA,  each  of  the  functions  listed  there  is  performed  primarily  by  one  or  more 
of  three  organizations  (TSM-FATDS,  TDS-CD-USAFAS,  and  USAFABD).  Figure  3-6 
shows  the  distribution  of  those  PDSS  functions  among  the  three  organizations. 
At  the  present  time,  most  of  the  functions  listed  are  being  performed  in 
support  of  the  TACFIRE  system. 

(3)  Requirements. 

(a)  Policies  and  procedures.  One  of  the  gaps  identified  in 
Paragraph  2-4. c. (7),  as  pertains  to  the  Fire  Support  BFA,  is  the  need  for  a 
regulatory  document  or  documents  which  address  four  particular  issues.  Each 
of  these  issues  is  discussed  below: 

1_.  A  direct  working  relationship  is  needed  between  the 
DARCOM  software  support  group  and  the  TRADOC  software  support  group.  This 
relationship  is  currently  being  handled  informally,  but  it  needs  to  be 
formalized  either  via  a  TRADOC  regulation  or  via  a  MOA  between  DARCOM  and 
TRADOC.  This  relationship  could  be  defined  as  a  direct  interface  between 
the  TSM  and  the  MD  for  each  system. 

2.  A  procedure  for  the  establishment  of  various  con¬ 
figuration  control  boards,  such  as  SCCB  and  FAICCB,  needs  to  be  spelled  out 
in  a  TRADOC  regulation.  This  procedure  should  spell  out  the  numbers  and 
types  of  members,  the  chairman,  the  frequency  of  meetings,  the  area  of  re¬ 
sponsibility,  etc.  for  each  board. 

3.  Current  TRADOC  regulations  do  not  provide  for  the 
updating  of  training  documents  in  connection  with  software  modifications. 
Since  many  software  modifications,  particularly  those  related  to  weapons 
system  equipment  updates  and  doctrinal  changes,  greatly  affect  the  User's 
interface  to  the  BAS,  training  documents  for  that  BAS  must  be  updated  in 
parallel  with  the  modification.  A  procedure  for  doing  this  needs  to  be 
formalized. 
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4_.  Current  TRADOC  regulations  do  not  provide  for 
the  funding  of  User  acceptance  testing  of  software  updates  for  deployed 
systems.  A  regulation  addressing  this  problem  is  needed. 

(b)  Organization.  It  is  not  expected  that  the  resolution 
of  any  of  the  above  issues  will  require  the  addition  of  new  organizations 
or  the  restructuring  of  existing  organizations.  However,  the  resolution 
of  some  of  the  issues  may  require  the  addition  of  personnel  to  existing 
organizations  which  are  understaffed. 

(c)  Resources.  Figure  3-7  shows  the  types  and  quantities 
of  personnel  which  would  be  required  to  establish  a  Combat  Developments 
Software  Support  Facility  (CDSSF)  at  Fort  Sill.  Of  the  personnel  shown, 
eleven  are  currently  on  board.  In  addition  to  the  personnel,  a  physical 
plant  to  house  the  CDSSF  and  equipment  for  an  operational  test  bed  would 
also  be  required. 

c.  Air  Defense  BFA. 

(1)  Systems  to  be  supported.  Figure  3-8  identifies  the  air 
defense  systems  requiring  or  anticipated  to  require  PDSS.  In  this  figure, 

PDSS  requirements  are  shown  as  starting  at  the  time  the  system  is  fielded. 

It  must  be  understood,  however,  that  planning  for  PDSS  must  precede  that 
date,  and  in  some  cases  the  planning  phase  may  involve  significant  lead 
times  and  substantial  resource  requirements.  Reference  may  be  made  to 
Chapter  2,  for  discussion  of  the  systems  identified.  In  Figure  3-8,  under 
the  "Other"  category  (line  8),  reference  is  included  to  an  air  defense 
control  system  to  support  the  Command,  Control  and  Subordinate  Systems 
(CCS^)  concept.  Although  the  CCS2  concept  refers  to  the  AN/TSQ-73  in  the 
role  of  such  an  air  defense  control  system,  there  is  reason  to  believe  that 
a  separate  entity  may  more  appropriately  evolve,  oriented  toward  the  needs 
of  CCS  .  Several  other  potential  systems  are  reflected  in  work  being 
conducted  at  various  levels  of  research.  It  is  relatively  certain  that  at 
least  one  of  these  potential  systems  will  eventually  become  a  responsibility 
under  this  BFA  and  impose  significant  PDSS  requirements.  It  appears  prudent 
to  anticipate  such  requirements  under  this  heading,  although  system  identifica 
tions  are  premature  at  this  time. 

(2)  Functions  to  be  performed.  The  common  functions  identified 
in  Paragraph  3-3,  above,  will  be  required  for  all  lines  shown  on  Figure  3-8. 
Additional  functions  or  functional  details  have  been  outlined  in  Chapter  2, 
Paragraph  2-4. d.,  for  this  BFA.  The  functions  to  be  performed  in  this 

BFA  are  at  least  as  comprehensive  as  those  of  other  BFA,  and  are  driven  by 
exceedingly  demanding  mission  and  technical  requirements. 
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(3)  Requirements. 

(a)  Policies  and  procedures.  Current  regulatory  authority, 
policies,  and  procedures  have  been  addressed  in  Paragraph  2-4. d.  of  Chapter 
2.  It  is  clear  that  implementation  of  PDSS  for  any  significant  system 
requires  that  detailed  procedures  be  worked  out  and  agreed  to  by  the  many 
parties  involved.  This  action  requires  resources.  It  is  also  clear  thart- — 
PDSS  plans  must  be  worked  out  and  agreed  to  well  before  the  system  is 
fielded,  if  the  capabilities  of  the  hardware  and  software  are  to  be  realized 
and  if  effectiveness  and  readiness  of  the  system  is  to  be  achieved.  This 
action  requires  that  the  required  resources  be  available  at  the  proper  time 
in  the  life  cycle  of  the  system.  Experience  to  date  strongly  indicates  that 
the  capability  to  provide  effective  PDSS  at  the  necessary  time  is  dependent 
on  many  prior  actions  and  preparations  that  cannot  be  overlooked.  To 
participate  effectively  in  either  the  provision  of  software  support  after 
deployment  or  the  planning  for  that  support,  personnel  must  be  familiar  with 
the  various  basic  technologies  involved,  the  system  itself,  its  mission,  and 
its  development  history.  For  example,  as  systems  and  their  software  increase 
in  complexity,  the  requirement  for  clear,  accessible  documentation  or  prior 
participation  in  the  development  of  the  system  becomes  more  of  a  necessity 

in  order  to  know  what  to  test  for,  how  to  test,  and  how  to  diagnose  problems. 
It  appears  that  current  policy  documents  do  not  give  appropriate  attention 
to  these  realities. 

(b)  Organization.  Research  to  date  in  this  BFA  does  not 
indicate  that  new  organization  and  organizational  requirements  are  a  signifi¬ 
cant  problem  at  this  time.  This  is  not  to  say  that  future  developments  may 
not  reveal  such  problems,  particularly  as  the  issues  of  how  to  add  resources 
are  addressed. 


(c)  Need  for  a  Combat  Developments  Support  Facility.  The 
necessary  tactical  doctrine  to  ensure  effective  employment  of  these  major  BAS 
was  never  thoroughly  developed  by  the  Combat  Developer  before  the  systems 
were  developed.  The  systems  are  about  to  be  fielded  with  software-embedded 
tactical  doctrine  developed  largely  by  the  contractor  and  Materiel  Developer. 
The  existing  software-embedded  tactical  doctrine  has  not  been  evaluated  by 
the  Combat  Developer,  and  evidence  suggests  it  may  be  suspect  or  at  least 
less  than  optimum  for  desired  system  effectiveness  in  an  integrated  air 
defense  environment.  It  is  felt,  within  the  AD  community,  that  a  software 
support  facility,  to  vastly  upgrade  CD  capabilities,  is  needed  to  permit  CD 
development  of  the  appropriate  tactical  doctrine  and  evaluation  of  that 
already  embedded  in  system  software,  so  that  necessary  corrective  actions  can 
be  taken  and  User  guidance  can  be  provided.  Because  the  systems  will  soon 
be  fielded,  the  overall  requirement  largely  falls,  or  will  soon  fall,  in  the 
category  of  post-deployment  software  support. 
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(d)  Resources.  Requirements  for  resources  (people,  facilities, 
and  equipment)  in  this  BFA  have  been  and  remain  a  principal  area  of  concern 
among  personnel  in  the  AD  community.  Intensive  attention  has  been  given  to 
this  issue  at  USAADS  over  the  past  two  or  more  years.  A  series  of  estimates 
of  resource  requirements  have  been  made  and  forwarded  to  higher  headquarters 
for  action.  While  some  resource  requests  in  limited  areas  have  been  granted, 
evidence  indicates  that  questions  remain  regarding  the  need  for  the  levels  of 
required  resources  estimated  for  PDSS. 

Several  obstacles  to  a  more  common  agreement  appear  to 
exist.  One  is  the  relative  newness  of  the  underlying  requirements,  evolving 
as  they  have  from  an  attempt  to  play  catch-up  in  air  defense  capability 
deferred  during  the  Vietnam  era.  A  second  obstacle  may  be  the  resulting 
sudden  introduction,  or  imminence  of  fielding,  of  several  major  air  defense 
systems,  at  least  two  of  which  involve  a  level  of  battlefield  automation 
complexity  and  interoperability  requirements  far  exceeding  any  previous  Army 
battlefield  systems.  Another  apparent  obstacle  to  agreement  is  simply  the 
magnitude  of  the  requirements  estimates  at  a  time  when  many  smaller  require¬ 
ments  which  do  seem  relatively  understandable  are  facing  intense  scrutiny  in 
the  interest  of  maintaining  budgetary  goals.  Another  difficulty  lies  in  the 
relationship  between  the  emergence  of  these  new  systems  and  the  need,  and 
rationale  for  the  need,  for  such  levels  of  resources  to  make  operationally 
effective  what  has  already  cost  billions  in  commitments  or  projected  commit¬ 
ments  for  systems  acquisition  alone. 

Furthermore,  there  appears  to  be  yet  another  dimension 
which  is  an  obstacle  to  agreement.  This  relates  to  the  definitional  issue 
of  what  is  clearly  a  post-deployment  problem,  at  one  point  in  time,  and  what 
may  be  necessary,  at  an  earlier  point  in  time,  in  order  to  effectively  prepare 
for  and  cope  with  the  post-deployment  problem.  As  has  already  been  alluded 
to  in  preceding  paragraphs  this  "definitional  issue"  is  really  not  as  simple 
as  it  sounds.  Also,  it  relates  to  the  more  fundamental  issues  of  how  the 
overall  combat  development  process  should  be  planned  and  conducted,  in  the 
context  of  the  total  life  cycle  of  any  system  acquisition  action. 

Many  estimates  of  resource  requirements  have  been  prepared 
at  USAADS,  including  a  very  significant  amount  of  detail.  Breakdown  details 
include  personnel  requirement  estimates  by  type  of  personnel,  by  system,  by 
year.  However,  because  of  the  volume  of  this  detail,  and  the  nature  of 
fundamental  definitional  issues  also  involved,  only  a  synopsis  of  those 
estimates  will  be  presented  in  this  report.  The  summary  numbers  are  presented 
in  Figure  3-9.  It  should  be  noted  that  these  numbers  include  not  only  the 
TRADOC  requirement  for  support  of  BAS  software  in  the  post-deployment  phase 
alone,  but  also  significant  requirements  relating  to  software  support 
throughout  the  overall  combat  development  and  system  acquisition  life  cycle 
process. 
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FISCAL  YEAR 

★ 

Total  Personnel  Required 

80 

81 

82 

83 

87 

105 

121 

122 

*  Includes  estimated  military,  civilian,  and 
contractor  support  personnel  in  both  mission- 
oriented  and  facility  support  functions  of 
combat  development  area.  Does  not  include  a 
requirement  within  the  Directorate  of  Training 
Developments  for  about  32  people  in  FY81  and 
subsequent  years  to  support  planning  for  and 
providing  PDSS  for  training  devices. 


Figure  3-9.  Estimated  total  personnel  requirements 
for  USAADS  Combat  Developments  Support 
Facility 


i 


3-24 


d.  Intelligence  and  Electronic  Warfare  BFA. 

(1)  Systems  to  be  supported.  The  Category  1  and  2  BAS  that 
impose  PDSS  requirements  within  this  BFA  were  identified  and  addressed 
in  Paragraph  2-4. e.  Figure  3-10  lists  these  same  BAS  and  identifies 
the  projected  time  when  each  system  is  to  be  deployed  and  PDSS  for  the 
deployed  systems  must  begin.  Early  PDSS  planning  must,  of  course,  be 
accomplished  concurrently  with  system  development  prior  to  the  projected 
deployment  shown  in  Figure  3-10. 

(2)  Functions  to  be  performed.  The  basic  functions  to  be 
performed  by  USAICS  systems  personnel  in  planning  for  and  providing  PDSS 
to  the  BAS  in  this  BFA  are  those  identified  in  Figure  3-3.  With  respect 
to  the  performance  of  these  functions,  USAICS  personnel  must  interact 
with  system  Users  and  with  ERADCOM  and  USACC,  the  Materiel  Developers  for 
all  BAS  being  addressed  in  this  BFA. 

(3)  Requirements. 

(a)  Policies  and  procedures.  No  significant  problems  were 
identified  with  respect  to  regulatory  authority  or  policies  applicable  to 
PDSS  for  BAS  in  the  Intel ligence/EW  BFA. 

(b)  Organization. 

1_.  PDSS  Coordination. 

a.  Research  conducted  during  Phase  I  of  this  study 
reveals  that  there  is  a  need  for  a  closer  relationship  at  the  working  level 
between  the  USAICS  and  ERADCOM  elements  involved  with  PDSS  for  BAS  in  the 
Intel ligence/EW  BFA.  Both  CD  and  MD  personnel  expressed  concern  over  the 
current  situation.  A  related  concern  is  the  apparent  need  for  more  particip¬ 
ation  by  CD  personnel  in  addressing  User-reported  system  problems  and 
functional  requirements. 


b^.  As  a  result  of  these  areas  of  concern,  there 
appears  to  be  a  requirement  for  a  USAICS  organizational  element  that  would 
serve  on  a  dedicated  basis  to  provide  an  interface  with  both  the  MD  and  User 
and  promote  the  working  level  CD-MD  and  CD-User  relationships  considered  to 
be  needed.  For  reference  purposes  in  this  report,  this  element  will  be 
called  the  USAICS  PDSS  Coordination  Element.  To  be  effective,  the  personnel 
in  this  USAICS  element  must  be  knowledgeable  of  the  operational  and  technical 
aspects  of  the  User's  operations  as  well  as  the  BAS  supporting  each  User. 

As  such,  they  can  provide  a  currently  missing  link  in  the  PDSS  process,  and 
a  communications  medium  between  the  User  and  the  MD.  This  would  contribute 
to  an  improved  CD  capability  to  state  functional  requirements  to  the  MD. 

This  capability  would  save  time  and  resources  that  are  currently  expended 
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UNCTIONAL 

ROPONENT 


USAICS 

USAICS 


BATTLEFIELD 
AUTOMATED 
SYSTEM  (BAS) 


AN/MSC-67— COMMUNICATIONS 
CENTER  (COMFAC) 

ASAS— ALL  SOURCE  ANALYSIS 
SYSTEM 


80  81  82  83  84  85 


USAICS  AN/TSQ-114 — TRAILBLAZER 

USAICS  AN/ALQ-1 51  — QUICKFIX 

USAICS  AN/TSQ-1 05— GUARDRAIL  V 

USAICS  AN/ALG-133— QUICKLOOK  II 

USAICS  SOTAS— STAND-OFF  TARGET 

ACQUISITION  SYSTEM 

USAICS  TCAC(O) — TECHNICAL  CONTROL 

AND  ANALYSIS  CENTER 
(DIVISION) 


Figure  3-10.  Systems  requiring  PDSS-Intel 1 igence 
and  Electronic  Warfare  BFA 
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when  requirements  are  not  completely  or  properly  stated  initially.  It 
would  also  place  the  CO  in  his  proper  role  of  examining  and  resolving  con¬ 
flicting  requests  and  requirements  from  different  users  of  the  same  system 
before  MO  resources  are  committed  to  their  solution. 

£.  It  should  be  noted  that  no  concern  was  expressed 
regarding  the  working  level  interaction  between  the  USAICS  personnel  involved 
with  the  COMFAC  system  and  the  current  System  Developers  in  USACEEIA.  The 
close  relationship  that  exists  relative  to  this  system  can  be  partially 
attributed  to  the  collocation  of  both  the  CD  and  MD  organizations  involved 
at  Ft.  Huachuca.  In  this  regard,  the  establishment  of  the  ERADCOM-managed 
PDSS  Center  for  ASAS  at  Ft.  Huachuca,  as  provided  for  in  the  PDSS  Concept 
Plan  for  BAS,  May  1980,  should  help  to  promote  closer  MD-CD  working  level 
interaction  on  the  ASAS.  PDSS  for  all  other  BAS  in  the  Intel! igence/EW  BFA 
is  to  be  provided  by  the  ERADCOM  PDSS  Center  at  Ft.  Monmouth.  The  USAICS 
PDSS  coordination  organization  referred  to  in  Paragraph  b,  above,  would  be 
responsible  for  interface  with  the  PDSS  Center  at  Ft.  Monmouth  on  actions 
involving  systems  supported  there. 

2_.  Other  requirements.  Two  additional  requirements 
were  identified  during  the  Phase  I  research  at  USAICS  that  relate  to  the 
need  for  an  improved  capability  to  develop  and  state  functional  requirements. 

£.  Both  CD  and  MD  personnel  indicate  that,  even 
when  functional  requirements  are  known,  the  CD  has  difficulty  in  stating 
these  requirements  to  the  MD  in  clear  meaningful  terms  to  facilitate 
system  development/change  programming.  Despite  dedicated  effort  by  CD 
personnel  involved,  requirements  usually  cannot  be  stated  in  the  degree 
of  detail  desirable.  There  is  a  language  barrier  or  gap  in  this  area. 

To  fill  this  gap,  there  is  a  need  for  a  software  requirements  definition 
language  to  assist  the  CD  in  stating  system  requirements.  Such  a  language 
would  be  beneficial  to  personnel  in  other  BFA  as  well. 

jj.  There  is  a  need  for  an  improved  analytical 
capability  to  support  the  definition  and  development  of  functional  require¬ 
ments.  This  capability  is  needed  to  support  analysis  to  determine  the 
impact  that  conceptual  changes  in  doctrine,  capabilities,  operational 
procedures,  or  the  threat,  have  on  existing  systems.  This  capability  is 
also  needed  to  analyze  the  impact  of  proposed  system  changes  on  the 
system  being  addressed  as  well  as  others  with  which  it  must  interoperate. 

(c)  Resources. 

1_.  PDSS  Coordination  Element. 

a_.  Initial  estimates  indicate  that  the  USAICS 
PDSS  Coordination  Element  referred  to  above,  should  consist  of  10  to  12 
professional  military  and  civilian  personnel.  This  estimate  is  based  on 
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requirements  to  accomplish  the  CO  PDSS  functions  identified  previously 
for  the  Intel! igence/EW  BFA  systems  requiring  or  projected  to  require  PDSS 
as  shown  in  Figure  3-3.  As  future  PDSS  requirements  increase,  the  size  of 
this  PDSS  Coordination  Element  may  have  to  be  increased  accordingly. 

b.  The  personnel  in  this  PDSS  Coordination 
Element  should  be  specialists  in  the  various  i n tel  1 igence/EW  disciplines 
associated  with  BAS  in  this  BFA,  and  should  have  secondary  specialties 
in  automatic  data  processing.  This  will  facilitate  their  interaction 
with  both  Users  and  the  MD  in  bringing  together  the  functional  and 
technical  aspects  of  a  system.  Mo  associated  facility  or  equipment 
requirements  have  been  identified  at  this  time.  This  initial  resource 
requirement  estimate  will  be  refined  and  developed  in  further  detail 
during  subsequent  study  phases. 

2.  Improved  analytical  capability  to  support  definition 
and  development  of  functional  requirements.  This  needed  capability, 
discussed  in  Paragraph  (b)  2.b,  above,  is  required  to  support  the 
accomplishment  of  CD  functions  associated  with  both  system  development 
and  system  changes  or  PDSS.  Requirements  in  this  area  are  being  addressed 
by  USAICS  at  present  in  a  three-phase  plan  for  increasing  the  capabilities 
of  the  Computer  Systems  Management  Office.  The  Simulations  Systems 
Management  Office  is  the  subordinate  organizational  element  that  would 
provide  the  improved  analytical  capability  under  this  plan.  If  it  is 
determined  that  there  is  a  need  to  address  analytical  capabilities  to 
support  PDSS  separately  from  the  above  plan,  this  will  be  accomplished 
in  coordination  with  USAICS  during  Phase  II  of  this  study. 

e.  Combat  Service  Support  BFA. 

(1 )  Logistics  Center. 

(a)  Systems  to  be  supported.  The  BAS  that  impose  PDSS 
requirements  within  this  BFA  were  identified  and  addressed  in  Paragraph 
2-4. e.  Figure  3-11  lists  these  same  BAS  and  identifies  the  projected  time 
when  each  system  is  to  be  deployed  and  PDSS  for  the  deployed  systems 
must  begin.  PDSS  planning  must,  of  course,  be  accomplished  concurrently 
with  system  development  prior  to  the  projected  deployment  shown  in 
Figure  3-11  . 


(b)  Functions  to  be  performed.  The  basic  functions  to 
be  performed  by  LOGCEN  Management  Information  Systems  Directorate  personnel 
in  planning  for  and  providing  PDSS  to  BAS  in  the  logistics  portion  of 
the  CSS  BFA  are  identified  in  Figure  3-3.  In  performing  these  functions, 
LOGCEN  personnel  must  interact  with  System  Users,  the  CSC  Support  Group, 

Ft.  Lee,  and  other  organizations  as  discussed  in  Paragraph  2-4. f. (1). 


< 


BATTLEFIELD 
AUTOMATED 
SYSTEM  (BAS) 
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LOGCEN/ 

DCSLOG 

USASC 

LOGCEN/ 

DCSLOG 

LOGCEN/ 

DCSLOG 

LOGCEN/ 

DCSLOG 

LOGCEN/ 

DCSLOG 

LOGCEN/ 

DCSLOG 

LOGCEN/ 

DCSLOG 

LOGCEN 

LOGCEN 


YEAR 


82  83  84  85 


DSU/GSU — DIRECT  SUPPORT  UNIT/ 
GENERAL  SUPPORT  UNIT 

DLDED 

SAMS— STANDARD  ARMY  MAIN¬ 
TENANCE  SYSTEM 

DLOGS — DIVISION  LOGISTICS 
SYSTEM 

MRM— MAINTENANCE  REPORTING 
AND  MANAGEMENT 

SAAS- 3— STANDARD  ARMY 
AMMUNITION  SYSTEM 

SAILS— ABX  STANDARD  ARMY 
INTERMEDIATE  LEVEL  SUPPLY 

DS4— DIRECT  SUPPORT 
STANDARD  SUPPLY  SYSTEM 

CSS  CONTROL  SYSTEM  _1 ^ 

PHOENIX 


mmm 


-1)  IN  COORDINATION  WITH  SOLD  ENTER 


Figure  3-1 1 . 


Systems  requiring  PDSS— Logistics  Center  Portion 
Combat  Service  Support  BFA 
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(c)  Requirements.  The  US  Army  Logistics  Center  has  many 
years  of  experience  in  providing  PDSS  to  fielded  systems  and  well 
established  procedures  for  providing  this  support.  Excellent  relationships 
exist  with  the  Logistics  Systems  Developer,  the  CSC  Support  Group,  Ft.  Lee, 
and  the  activities  of  each  organization  are  closely  coordinated  to  provide 
the  most  effective  and  responsive  support  possible  to  the  user.  This 
support  ranges  from  emergency  customer  assistance  to  scheduled  installation 
of  system  change  packages  designed  to  improve  a  system's  capability  to 
satisfy  important  user  requi rements.  As  a  result  of  this  capability, 
no  additional  PDSS  functional  or  resource  requirements  were  identified 
which  affect  the  LOGCEN. 

(2)  Soldier  Support  Center. 

(a)  Systems  to  be  supported.  Figure  3-12  identifies  the 
systems  anticipated  to  require  PDSS  and  indicates  when  such  support  re¬ 
quirements  may  begin  and  end  for  each  system.  In  this  figure,  PDSS 
requirements  start  at  the  time  the  system  is  fielded,  although  it  must  be 
understood  that  some  planning  for  PDSS  must  precede  that  date.  PDSS 
requirements  for  SIDPERS,  SIDPERS  Wartime,  and  the  DLDED  Personnel 
Software  Package  are  seen  as  being  satisfied  by  MILPERCEN  and  CSC,  with 
SSC  PDSS  involvement  restricted  to  monitoring.  The  third  line  in  this 
figure,  labeled  Software  Conversion  for  New  Hardware,  is  not  system-specific, 
as  explained  in  Paragraph  2-4. f. (2) (a)^,  above.  In  the  case  of  this  line, 
PDSS  is  construed  to  begin  at  the  outset  of  detailed  planning,  since  the 
various  systems  to  be  affected  by  hardware  change  are  already  fielded. 
Additional  comments  or  qualifications  for  lines  3  through  7  are  provided 

in  the  footnotes  to  this  figure.  SSC  PDSS  requirements  with  respect  to 
VFDMIS,  TAPER,  and  VTAADS  may  be  restricted  to  monitoring  and  to 
interoperabili ty  considerations. 

(b)  Functions  to  be  performed.  Because  substantive  PDSS 
requirements  for  which  SSC  is  anticipated  to  be  responsible  are  one  to 
three  years  in  the  future,  little  can  be  said  at  this  time  regarding 
specific  functions  to  be  performed,  other  than  what  has  been  covered  in 
Paragraph  3-3,  above.  The  general  or  comnon  PDSS  functions  identified 
in  that  paragraph  will  apply  to  those  systems  for  whicn  SSC  will  have 
substantive  responsibility  (lines  3  thru  6  on  Figure  3-12).  In  Software 
Conversion  for  New  Hardware,  line  3,  SSC  functions  may  well  be  more 
limited  than  Paragraph  3-3  might  suggest.  Line  6,  Interfaces  with 
TAMMIS,  it  should  be  emphasized,  is  to  address  only  PDSS  of  tne  interfaces 
between  TAMMIS  and  personnel  systems,  and  not  TAMMIS  itself,  which  will 

be  the  responsibility  of  Health  Services  Command.  SSC  PDSS  responsibilities 
with  respect  to  Line  7,  PWIS  are  not  clear  at  this  time,  and  may  be  quite 
limited.  As  noted  in  the  preceding  paragraph,  SSC  responsibilities  for 
VFDMIS,  TAPER,  and  VTAADS,  may  be  limited  primarily  to  interoperability 
issues. 
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(c)  Requirements. 

Policies  and  procedures.  Regulatory  authority, 
policies,  and  related  issues  have  been  discussed  at  some  length,  in 
Paragraphs  2-4.f.(2)(c),(d),(f),  and  (g),  above.  In  the  last  of  those 
paragraphs,  a  number  of  apparent  regulatory  overlaps  and  other  problems 
were  identified.  Based  on  research  to  date,  it  seems  that  some  clarifi¬ 
cation  of  these  issues  would  be  desirable,  although  no  specific  sugges¬ 
tions  have  yet  been  recorded  regarding  proposed  vehicles,  forms,  or 
contents  for  such  clarifications.  These  matters  will  be  addressed 
further  in  later  phases  of  this  study  effort. 

2_.  Organization.  Some  organizational  changes  and 
realignments  have  been  made--some  very  recently,  as  indicated  in 
Paragraph  2-4. f.  It  appears  that  a  less-than-complete  understanding  of 
these  organizational  changes  exists  among  parties  involved.  Preliminary 
evidence  indicates  that  some  substantive  issues  may  remain  to  be  resolved. 

2-  Resources.  A  preliminary  discussion  of  personnel 
resources  required  to  perform  a  broad  set  of  combat  development,  fielding 
support,  and  maintenance  functions,  with  emphasis  on  PDSS,  was  held  at 
SSC  on  3  September  1980.  During  this  discussion,  estimates  were  made  of 
the  total  number  of  people  needed  by  fiscal  years  1980-1986  and  by 
system  or  major  category,  as  shown  in  Figure  3-13.  Both  MILPERCEN 
and  SSC  were  represented  in  that  discussion,  and  the  estimates  are 
intended  to  represent  the  perceived  total  requirements  of  both  those 
organizations.  Breakout  between  MILPERCEN  and  SSC,  however,  is 
discernible.  A  further  breakdown  into  specific  functions,  and  PDSS 
alone  is  generally  not  identified.  Also,  systems  appear  in  Figure  3-12 
that  were  not  specifically  addressed  in  the  estimates  appearing  in 
Figure  3-13.  Furthermore,  resources  other  than  personnel  (e.g.,  facilities, 
equipment,  other)  were  not  addressed  during  that  discussion.  Nevertheless, 
these  estimates  do  provide  an  indication  of  the  resource  requirements, 
and  can  serve  as  a  basis  for  refinement.  Generally  speaking,  SSC  and 
MILPERCEN  representatives  stated  that  30  people  are  now  needed  for  what 
is  essentially  combat  development-side  PDSS  of  existing  personnel /admin 
systems.  The  level  needed  for  PDSS  can  be  anticipated  to  increase 
gradually  as  additional  systems  are  involved,  reaching  about  the  35+ 
level  by  1985/86.  These  numbers  do  not  include  personnel  also  needed  to 
perform  other  combat  development  functions  such  as  requirements  and 
concepts  definition,  supervision  and  monitoring  of  development,  involve¬ 
ment  in  developmental  testing  and  evaluations  and  operational  and  user 
issues,  and  extension  of  new  systems  to  the  field.  In  the  1983/84 
period,  if  monitoring  and  supervising  development  of  a  new  personnel  system 
and  other  developments  are  included,  the  numbers  are  projected  to  reach 
the  90  level,  not  including  support  of  fielding.  In  1984,  an  additional 
50  people  are  seen  needed  for  6  to  12  months  to  support  fielding.  None 
of  these  numbers  include  efforts  on  the  system/materiel  developer  side  of 
the  house.  Figure  3-13  provides  also  an  indication  of  the  difficulty 
involved  in  clearly  separating  PDSS  from  related  requirements. 
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f .  Maneuver  BFA. 

(1)  Systems  to  be  supported.  The  Advanced  Attack  Helicopter  (AAH) 
is  the  only  Category  1  or  2  BAS  projected  to  require  PDSS  support  in  the 
Maneuver  BFA.  PDSS  will  be  required  for  this  Category  2  system  following 
projected  deployment  in  1982  as  shown  in  Figure  3-14.  PDSS  planning  actions 
will  have  to  be  accomplished  prior  to  that  time. 

(2)  Functions  to  be  performed.  Basic  functions  to  be  performed  by 
the  CD  in  planning  for  and  providing  PDSS  to  this  system  are  those  identified 
in  Figure  3-3.  The  US  Army  Aviation  Center,  the  Combined  Arms  Concepts  Divi¬ 
sion  of  the  Concepts  and  Doctrinal  Management  Directorate,  the  Army  C2/JINTACCS 
Division  of  the  C3I  Directorate,  and  the  Combat  Division,  Materiel  Integration 
Directorate,  CACDA,  are  the  CD  organizations  primarily  involved  with  this  system. 
They  must  interface  with  the  PM  AAH  on  matters  pertaining  to  the  development  and 
post-deployment  support  of  this  system.  At  this  time,  no  PDSS  Center  has  been 
designated  to  support  the  AAH.  The  PDSS  Concept  Plan  for  BAS  states  that  a 
Center  will  be  designated  at  the  time  of  transition. 

(3)  Requirements.  No  functional  or  resource  requirements 
needed  for  providing  PDSS  to  BAS  within  this  BFA  have  been  identified  at 
this  time  other  than  those  CD  personnel  currently  involved  with  the  AAH. 

g.  Communications  functional  area. 

(1)  Systems  to  be  supported.  Within  the  communications  functional 
area  there  are  currently  ten  category  1  and  2  systems  which  will  require 
PDSS.  These  systems  were  described  in  Paragraph  2-4. h. ( 1 ) .  and  are  itemized 
in  Figure  3-15  with  an  indication  of  when  PDSS  will  be  required. 

(2)  Functions  to  be  performed.  The  basic  functions  to  be  performed 
by  USASC  systems  personnel  in  planning  for  and  providing  PDSS  to  the  BAS  in 
the  communications  functional  area  are  those  identified  in  Figure  3-3.  The 
only  unique  functions  which  they  might  perform  are  those  associated  with 
TRI-TAC.  Since  TRI-TAC  involves  all  Service  branches  as  well  as  NSA  and  DCA, 
there  will  be  some  functions  to  be  performed  which  are  not  directly  covered 

in  Figure  3-3. 

(3)  Requirements. 

(a)  Policies  and  procedures.  The  only  requirement  expressed 
in  the  area  of  PDSS  procedures  is  the  need  for  a  streamlined,  responsive 
procedure  to  effect  identified  improvements  to  a  system  without  the  require¬ 
ments  of  developing  a  new  Required  Operational  Capabilities  (ROC)  document 
and  without  the  processing  normally  associated  with  it. 

(b)  Organization.  Only  if  the  solution  to  the  above  re¬ 
quirement  should  include  the  establishment  of  a  Combat  Developments  Software 
Support  Facility  at  Fort  Gordon,  would  any  new  organizations  be  required  to 
maintain  PDSS  for  the  communications  functional  area. 
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Figure  3-15.  Systems  requiring  PDSS— Communications  Functional  area 
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CHAPTER  4 


GENERAL  ISSUES  AND  POTENTIAL  PROBLEMS 

4-1.  GENERAL.  This  chapter  describes  general  issues  and  potential  problem 
areas  that  have  been  identified  during  the  initial  phase  of  this  study  and, 
where  appropriate,  discusses  insights  and  implications  for  TRADOC  based  on 
research  and  analysis  to  date.  Further  research  and  analysis  during  Phase 
II  may  result  in  development  of  additional  information  relative  to  these 
subject  areas. 

4-2.  AREAS  IDENTIFIED. 

a.  Regulatory  Authority  and  Policy.  Regulatory  policy  governing  the 
acquisition  and  life  cycle  management  of  automatic  data  processing  systems  in 
the  Army  is  divided  between  two  sets  of  regulations--the  AR  18-series,  and  AR 
1000-1  and  the  AR  70-series.  Generally,  BAS  in  the  CSS  BFA  have  been  acquired 
under  AR  18-1  while  other  BAS  have  been  acquired  and  managed  under  ARs  1000-1 
and  70-1.  However,  there  are  differences  in  interpretation  with  respect  to 
the  applicability  of  these  regulations.  This  is  a  source  of  irritation  and 
potential  problems  among  organizations  and  personnel  involved  with  BAS  within 
TRADOC.  Efforts  have  been  made,  through  the  recent  revision  (August  1980)  to 
AR  18-1  and  the  pending  revisions  to  ARs  1000-1  and  70-1,  to  clarify  their 
applicability  and  minimize  differences  between  these  regulations,  to  the  extent 
that  this  can  be  done  and  still  comply  with  Public  Law  and  0MB  policy.  The 
memorandum  from  the  Assistant  Secretary  of  Defense  (Research  Development,  and 
Acquisition),  1  July  1980,  subject:  "Standardization  of  Embedded  Computer  Re¬ 
sources,"  and  letter  from  the  Deputy  Commander,  TRADOC,  file:  ATDC,  dated  30 
July  1980,  same  subject,  discussed  in  Paragraph  2-3. d.,  also  promulgate  policy 
relative  to  this  problem  area.  To  further  clarify  this  policy  following 
publication  of  the  revised  ARs  1000-1  and  70-1,  further  effort  should  be  de¬ 
voted  to  insuring  that  there  is  full  understanding  and  agreement  on  the 
applicability  of  these  regulations  and  the  recently  published  AR  18-1. 

b.  Adequacy  of  Army  Regulations.  The  post-deployment  period  of  the 
system  life  cycle  in  general ,  and  post-deployment  software  support  in  partc- 
ular,  have  not  been  addressed  sufficiently  in  the  basic  Army  regulations 
governing  system  acquisition  and  life  cycle  management  (i.e.,  AR  1000-1,  AR 
70-1,  and  AR  18-1).  DARC0M  and  CSC  regulations  have  helped  to  fill  this  gap 
some  with  respect  to  the  Materiel /System  Developer's  requirements  but  there 
is  no  comparable  regulation  addressing  the  Combat  Developer's  requirements. 

The  new  August  1980  AR  18-1  does  address  the  "Deployment  and  Operation  Phase" 
of  the  system  life  cycle  in  greater  detail  and  a  review  of  portions  of  drafts 
of  revised  ARs  1000-1  and  70-1  indicate  that  post-deployment  requirements  are 
also  being  addressed  more  in  those  regulations.  For  example,  in  the  revised 
AR  70-1,  an  entire  chapter  is  being  devoted  to  the  acquisition  and  management 
of  computer  resources  including  post-deployment  support  to  these  resources. 

A  TRADOC  companion  regulation  to  DARC0M  Reg  71-16  implementing  the  new  pro¬ 
visions  of  AR  70-1  is  needed.  In  addition,  the  DARC0M-TRAD0C  Materiel  Acquisi¬ 
tion  Handbook  needs  to  be  updated  to  reflect  the  revised  policies  of  these  Army 
regulations  and  of  D0D  Instruction  5000.2. 
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c.  Cascade  of  Training  Requirements.  In  complex,  heavily  automated 
BAS,  training  software  may  be  incorporated  in  the  BAS  itself  to  further 
operator  proficiency.  Separate  training  devices  tend  also  to  be  required  to 
train  operators  and  maintainers.  The  separate  training  devices  are  required 
primarily  for  institutional  training  of  new  personnel,  refresher  training, 
etc.  The  training  resource  requirements  implications  of  these  built-in  and 
separate  training  devices/capabilities  may  extend  (or  cascade)  over  several 
levels.  First,  the  training  software  in  the  BAS  and  the  separate  devices 
must  be  properly  specified  and  managed  throughout  its  development.  Second, 
the  separate  devices  themselves  must  be  properly  planned  and  acquired,  with 
the  training  goals  clearly  in  sight.  Third,  the  built-in  and  separate 
training  devices  probably  will  require  training  scenarios  to  exercise  the 
training  software.  Fourth,  preparation  of  the  scenarios  will  probably  re¬ 
quire  personnel  familiar  with  the  BAS  and  its  operation,  and  hence,  present 
an  early-on  requirement  for  training  of  these  personnel.  This  requirement 
in  turn  poses  a  fifth  requirement  for  simulators  of  the  BAS  which  can  be 
used  as  initial  training  devices.  Sixth  such  simulators  must  have  software 
and  driver  scenarios.  When  changes  are  made  to  any  significant  aspect  of 
basic  software  in  the  BAS  (whether  that  change  is  caused  by  a  change  in 
threat,  doctrine,  environment,  interoperability  conditions/requirements,  or 
hardware  itself),  then  corresponding  changes  will  need  to  be  reflected  at 
all  but  the  second  of  the  six  levels  identified  above.  Implementing  such 
changes  further  requires  a  PDSS  effort  almost  wholly  relating  to  the  training 
area--new  scenarios,  new  software,  training  in  the  changes,  etc.  All  of 
these  functions  and  steps  require  properly  qualified  personnel,  and  many 
require  space,  facilities,  equipment,  and  other  funding  for  development  and 
maintenance  support.  This  phenomenon  of  cascading  training  resource  require¬ 
ments  appears  not  to  be  generally  recognized,  but  will  be  encountered  with 
many  more  BAS  in  the  not-too-distant  future. 

d.  Need  for  Simulation/Experimentation/Analysis  Capability.  Generally, 
a  need  is  seen  to  exist,  at  any  TRADOC  center  which  is  to  carry  significant 
combat  development  responsibilities,  for  a  simulation/experimentation/analysis 
capability.  Development  of  system  and  system  software  requirements  is  a 
major  responsibility  of  both  the  User  and  the  Combat  Developer,  as  User 
Surrogate.  At  the  front  end  of  both  the  system  life  cycle  and  the  life  of 
system  changes,  development  of  requirements  actually  extends  from  the  study 
phase  through  the  end  of  the  system  life  cycle.  Development  of  requirements 
is  more  than  simply  identifying  and  describing  a  need.  Development  of 
requirements  is  an  exacting  function  which  requires  detailed  insight  into 

the  potential  behavior  of  system  variables,  their  tradeoffs,  and  payoffs. 

This  requires  in  many  cases  a  range  of  computerized  models  and  simulations, 
from  aggregative,  low- resolution  analytical  models  to  detailed,  high-resolu- 
tion,  high-fidelity  probabilistic  simulations.  Such  models  and  simulations 
are  required  because,  in  even  a  modestly  complex  system  of  variables,  the 
interrelations  among  these  variables  are  far  beyond  the  capability  of  the 
unaided  human  mind  to  evaluate.  Such  analytical  tools  can  permit  detailed 
evaluation  of  user  requirements  to  insure  that  they  are  appropriate,  complete, 


consistent,  and  testable,  prior  to  their  transfer  to  the  Materiel  Developer. 
The  trend  of  embedding  in  software  more  and  more  of  the  vital  doctrinal  and 
tactical  functions  and  operating  procedures  dictates  a  much  deeper  level  of 
specificity  of  User  requirements  than  is  commonly  provided  to  the  Materiel 
Developer  or  is  called  for  in  procedures  for  writing  requirements  documents. 
This  evolving  trend  not  only  demands  that  User  Representatives  amplify  the 
depth  of  detail  in  their  tactical  software  requirements  specifications  but 
also  dictates  a  much  closer  involvement  with  the  Materiel  Developer  through¬ 
out  system  development,  testing,  and  post-deployment  support.  The  alterna¬ 
tive  is  to  abdicate  Combat  Developer  responsibilities  to  the  program 
managers  and  contractors.  Experience  has  shown  such  abdication  to  be  a 
very  costly  mistake.  The  same  analytical  capabilities  needed  for  development 
of  system  and  system  software  requirements  are  needed  to  guide  and  support 
User  acceptance  and  other  testing,  to  determine  training  requirements  for 
devices  and  programs,  and  to  evaluate  new  concepts,  tactics,  and  doctrine, 
in  response  to  changes  in  technology,  threat,  mission,  and  environment.  The 
rationale  for  these  other  needs  for  a  simulation/experimentation/analysis 
capability  is  much  the  same  as  that  enunciated  above.  Finally,  it  should  be 
emphasized  that  such  a  capability  is  applicable  to  the  needs  of  both  the 
pre-deployment  and  the  post-deployment  combat  development  responsibilities, 
of  which  FDSS  is  one  aspect. 

e.  System  and  Software  Requirements  Definition.  One  of  the  Combat 
Developer's  principal  functions  in  the  PDSS  process  is  defining  system  and 
software  requirements  in  clear  meaningful  terms  to  the  Materiel  Developer. 
Phase  I  research  indicates  that  in  many  cases,  this  poses  serious  difficulties 
for  the  Combat  Developer  even  when  functional  requirements  are  well  known. 
There  appear  to  be  communication  gaps  between  statements  of  functional 
requirements  and  the  software  written  to  satisfy  those  requirements.  The 
development  or  acquisition  of  a  "Software  Requirements  Definition  Language" 

to  assist  the  Combat  Developer  in  defining  and  stating  requirements  should 
be  a  major  step  in  filling  the  gap  that  currently  exists.  Also  closely 
related  to  the  problem  of  requirements  definition  is  the  need  for  simulation 
and  analytical  capabilities  to  support  this  process  as  described  in 
Paragraph  d. 

f.  Implications  of  DODI  5000.2.  DODI  5000.2:  Major  Systems  Acquisi¬ 
tions  Procedures,  19  March  1980,  provides  supplementary  procedures  for  use 
in  implementing  DODD  5000.1:  Major  Systems  Acquisition.  Paragraph  13  of 
DODI  5000.2,  authorizes  an  alternate  acquisition  procedure  for  major  or 
nonmajor  command  and  control  systems  that  are  to  be  acquired  in  limited 
numbers  and  meet  certain  other  criteria.  This  alternate  procedure  provides 
that  after  approval  by  the  Secretary  of  Defense  of  a  MENS  for  such  a 
system,  the  design  and  testing  of  the  system  may  be  accomplished  in  an 
evolutionary  manner.  The  system  would  be  configured  initially  as  a  pro¬ 
totype  using  existing  military  or  commercial  equipment  to  the  maximum  extent 
possible  and  with  minimum  additional  software.  Designated  Users  would  test 
various  configurations  in  operational  environments.  The  end  result  would 
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be  a  definition  of  a  system,  including  operational  software,  tailored  to 
meet  the  User  needs.  While  this  procedure  has  many  apparent  advantages,  it 
also  has  a  number  of  implications  that  need  to  be  considered  with  respect 
to  configuration  control,  post-deployment  support,  training  requirements,  and 
other  related  areas. 

2 

g.  Configuration  Control  Boards  (CCB).  The  ECS  concept  for 
battlefield  automation  and  the  requirement  for  interoperability  among  BAS 
within  this  concept  appears  to  make  the  establishment  of  a  hierarchy  of 
configuration  control  boards  desirable.  One  concept  for  the  structure  of 
this  hierarchy  would  include  CCB  at  each  of  the  three  levels  of  the  ECS^ 
concept  as  follows: 

•  Executive  System  Level:  One  CCB  to  exercise  configuration  manage¬ 
ment  for  the  Executive  System  and  the  interoperability  require¬ 
ments  between  this  system  and  the  control  systems  with  which  it 
must  interface 

•  Control  System  Level:  One  CCB  for  each  control  system  (e.g.,  ASAS, 
TACFIRE)  to  exercise  configuration  management  for  each  control 
system  and  its  interoperability  with  each  of  its  supporting 
systems 

t  Support  System  Level :  One  CCB  for  each  system. 

This  concept  has  been  partially  implemented  in  some  BFA,  but  needs  to  be 
fully  implemented  across  all  BFA.  Also,  while  the  Materiel  Developer  has 
primary  responsibility  for  configuration  management,  the  Combat  Developer 
must  participate  actively  in  this  effort.  The  establishment  of  an  effective 
system  for  exercising  the  required  degree  of  control  over  all  BAS  should 
be  of  concern  to  all  organizations  involved  with  these  systems. 

h.  Personnel  Resources.  Acquisition  of  the  required  capability  to 
fulfill  the  Combat  Developer's  role  in  planning  for  and  providing  PDSS  for 
BAS  will  probably  involve  additional  personnel  resources  although  all 
specific  requirements  have  not  been  identified  at  this  time.  The  acquisition 
of  additional  resources  poses  a  very  difficult  problem  in  view  of  the 
constraint  on  personnel  resources  throughout  the  Army  at  the  present  time. 

i.  Crisis/Wartime  Support.  This  is  one  of  the  most  important  areas 
to  be  addressed  in  any  plan  or  system  intended  to  provide  PDSS  to  BAS. 

There  are  so  many  unique  system-related  aspects  of  providing  PDSS  support 
in  crisis/wartime  that  no  single  plan  or  concept  can  be  applied  to  all  BAS. 

In  devising  an  appropriate  wartime  support  plan  and  capability,  the  nature, 
role,  and  criticality  of  each  system  must  be  addressed  as  well  as  its 
location  on  the  battlefield.  The  nature  and  likelihood  of  change  in  the 
threat  with  which  the  system  must  contend  is  a  major  factor  in  PDSS  planning. 
The  friendly  plan  of  operations  and  interoperability  requirements  are  other 
major  factors  that  must  be  considered.  There  are  also  conflicting  interests 
and  requirements,  e.g.,  rapid  response  through  interim  changes  and  work-around 
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procedures  versus  the  need  to  maintain  configuration  control.  All  this 
emphasizes  the  need  for  joint  Combat  Developer-Materiel  Developer  addressal 
of  this  subject  early  in  each  system  development  effort.  This  subject  will 
also  be  addressed  further  in  subsequent  phases  of  this  study. 

j.  Where  Do  We  Get  The  Necessary  People?  The  software  support 
resource  requirements  which  appear  to  be  emerging  from  this  study  raise 
some  fundamental  questions  that  may  deserve  addressal  here.  Effective 
performance  of  combat  development  software-oriented  functions,  upon  which 
combat  readiness  and  effectiveness  of  vital  weapons  systems  increasingly 
is  coming  to  depend,  requires  in  most  cases,  within  each  individual,  a 
demanding  blend  of  software  skills  and  experience,  military  doctrinal  and 
weapon  system  understanding,  and  basic  understanding  of  the  technology  on 
which  the  weapon  systems  depend.  These  skills  also  need  to  be  reasonably 
up  to  date.  Since  the  supply  of  such  types  of  people  is  limited,  and  the 
numbers  required  appear  to  be  relatively  large,  an  initial  question  arises: 
Where  could  such  additional  people  be  obtained  to  satisfy  requirements? 

This  initial  question  raises  several  additional  questions.  First,  is 
necessary  support  being  given  to  training  of  the  types  of  people  who  will 
be  needed?  This  question  would  apply  to  both  in-house  Army  training  (e.g., 
note  the  cancellation  of  the  1181  missile  officer  course  at  USAADS  in  1977) 
and  possible  support  or  encouragement  that  might  be  provided  to  local  private 
educational  institutions.  Particularly  in  the  area  of  automation  and 
information  sciences  skills,  projected  demands  of  industry  alone  appear  to 
far  exceed  the  probable  supply  of  graduates.  Such  scarcity  may  rapidly 
escalate  compensation  and  otherwise  present  difficult  or  insuperable 
problems  to  Army  acquisition  and  retention  of  the  necessary,  qualified 
people.  Second,  do  the  necessary  educational  facilities/institutions 
exist?  And,  finally,  what  steps  should  be  taken  to  maximize  Army  retention 
and  utilization  of  the  necessary  skills?  For  instance,  should  a  Warrant 
Officer  specialist  career  path  be  considered  to  permit  the  specialization 
and  stability  of  tenure  which  may  be  needed  in  performing  some  of  these 
functions? 


k.  Issue  Concerning  The  Proper  Scope  of  Study.  From  the  inception 
of  this  study  effort,  it  has  been  apparent  that  a  basic  issue  or  disagree¬ 
ment  exists  concerning  what  is  the  proper  scope  of  study.  While  the 
Statement  of  Work  and  other  elements  of  the  RFP  have  clearly  designated 
that  this  study  effort  was  to  address  only  post-deployment,  opinions  have 
clearly  been  expressed  in  several  quarters  that  both  pre-  and  post-deploy¬ 
ment  software  support  should  be  addressed.  In  the  latter  view,  the  proper 
scope  would  include  addressal  of  the  entire  combat  development  process 
pertaining  to  systems  acquisisition  and  life  cycle  management.  This  view 
suggests  a  need  either  to  expand  the  scope  of  this  study  or  to  address  the 
larger  area  in  another  study. 
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APPENDIX  B 
GLOSSARY 


Administration  --  This  functional  area  which  is  included  in  the  Combat  Service 
Support  BFA,  supports  the  commander  in  seeing  the  battlefield  (friendly 
personnel  situation)  and  in  sustaining  the  forces.  Indirect  support 
also  exists  through  assistance  to  other  functional  areas  and  to  the 
soldiers  who  man  them. 

Air  Defense  Artillery  —  This  BFA  reacts  to  and  defeats  a  varied  and  growing 
aircraft  and  countermeasures  threat  under  all  environmental  and  tactical 
conditions  and  in  all  intensities  of  combat. 

Air/Ground  —  This  functional  area  which  is  included  in  the  Maneuver  BFA, 
relies  on  the  harmonious  interaction  of  the  Army  Air/Ground  Subsystem 
(AAGS)  and  the  Air  Force  Tactical  Air  Control  Subsystem  (TACS),  through 
the  Air  Force  Tactical  Air  Control  Center  (TACC),  to  jointly  provide 
the  personnel,  procedures,  and  equipment  necessary  to  plan,  coordinate 
and  execute  Tactical  Air  Support  missions. 

Automation  —  The  technique  of  incorporating  computer  resources  within 
systems  or  processes  to  make  those  systems  or  processes  operate,  in 
whole  or  in  part,  automatically. 

Automatic  Test  Equipment  (ATE)  —  Computer  resources  used  to  isolate  facility 
electronic  components  for  repair  or  replacement. 

Battlefield  Automated  System  (BAS)  —  A  system  intended  for  use  by  the  Army 
in  the  field  which  contains  a  computer(s)  and  which  will  not  function 
without  computer(s);  e.g.,  AN/TSQ-73,  TACFIRE. 

Battlefield  Functional  Area  (BFA)  —  The  concept  which  describes  the  actions 
systems  perform  and  the  arena  in  which  they  operate  in  accomplishing  the 
commander's  mission  of  viewing  the  battlefield,  planning  operations, 
allocating  resources,  fighting  the  battle,  and  sustaining  the  force. 

Combat  Developer  --  The  agency  or  command  responsible  for  the  formulation  of 
concepts,  doctrine,  organization,  and  materiel  objectives,  and  require¬ 
ments  for  the  employment  of  U.S.  Army  Forces  in  a  theater  of  operations 
and  in  the  control  of  civil  disturbances.  The  Combat  Developer  formulates 
Army  functional  systems  (logistics,  personnel,  administrative,  and 
others,  as  designated)  which  impact  directly  on  or  extend  into  a  theater 
of  operations.  The  U.S.  Army  Training  and  Doctrine  Command  (TRADOC)  is 
the  Army's  principal  Combat  Developer. 
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Combat  Development  Support  Facility  (CDSF)  —  The  CDSF  is  a  TRADOC  analytical 
facility  which  encompasses  one  or  more  BFAs  and  which  may  or  may  not  be 
collocated,  in  whole  or  in  part,  with  an  MD  PDSS  facility  at  the  TRADOC 
doctrine  center  or  school.  The  CDSF  has  as  its  primary  purpose  the 
provision  of  both  the  system/ software  analytical  capability  and  the 
technical  personnel  necessary  to  perform  CD  functions  in  the  develop¬ 
ment,  maintenance,  application,  and  training  for  BAS  in  order  to 
develop,  field,  use,  sustain,  and  evolve  these  systems. 

Combat  Development  System  Manager  (CDSM)  —  The  Combat  Developments  System 
Manager  (CDSM)  is  the  system/software  CD  and  the  principal  field  user's 
representative  for  a  designated  system  or  systems.  The  CDSM  is  respon¬ 
sible  for  managing  and  coordinating  and/or  performing  all  software  - 
related  actions  inherent  in  the  CD  mission.  The  CDSM  is  also  responsible 
for  planning,  programming,  and  coordinating  those  software  tasks  required 
to  be  performed  by  the  CDSF  in  support  of  the  systems  for  which  he  is 
responsible. 

2 

Command  and  Control  (C  )  —  This  functional  area  is  the  exercise  of  the 

inherent  authority  of  a  commander  to  plan,  direct  and  monitor  implemen¬ 
tation  of  tasks  by  subordinate  elements  within  all  Battlefield 
Functional  Areas. 

Communications  --  This  functional  area  provides  the  mechanism  by  which  the 
commander  controls  all  other  battlefield  functions  in  the  performance 
of  his  mission. 

Computer  —  Electronic  machinery  which,  by  means  of  stored  instructions  and 
data,  performs  rapid  complex  calculations  or  compiles,  correlates,  and 
selects  data.  Examples  are  analog  and  digital  processors,  data  pro¬ 
cessors,  information  processors,  real-time  control  processors,  electronic 
calculators,  hybrid  computers,  communications  processors,  and  micro-pro¬ 
cessors. 

Computer  Data  --  A  representation  of  facts,  concepts,  or  instructions  in  a 
structured  form  suitable  for  acceptance,  interpretation,  or  processing 
by  communication  between  computer  equipment.  Such  data  can  be  external 
to  (in  computer-readable  form)  or  resident  within  the  computer  equipment 
and  can  be  in  the  form  of  analog  or  digital  signals. 

Computer  Equipment/Computer  Hardware  —  Devices  capable  of  accepting  and 

storing  computer  data,  executing  a  systematic  sequence  of  operations  on 
computer  data,  or  producing  computer  outputs.  Such  devices  can  perform 
substantial  interpretation,  computation,  communication,  control,  or  other 
logical  functions.  Examples  are  central  processing  units,  terminals, 
printers,  analog/digital  converters,  tape  drives,  disks,  micro-processors, 
and  automatic  test  equipment. 

Computer  Firmware  --  Programs  or  instructions  that  are  stored  in  read-only 
memory;  firmware  is  software  in  unalterable  form.  Firmware  is  software 
regardless  of  the  media  on  which  it  is  stored. 


Computer  Program  —  A  series  of  instructions  or  statements  in  a  form 
acceptable  to  computer  equipment,  designed  to  cause  the  computer 
equipment  to  execute  an  operation  or  operations.  Computer  programs 
include  operating  systems,  assemblers,  compilers,  interpreters,  data 
management  systems,  utility  programs,  sort-merge  programs,  and  main¬ 
tenance/diagnostic  programs,  as  well  as  applications  programs  such  as 
payroll,  inventory  control,  operational  flight,  satellite  navigation, 
automatic  test,  crew  simulator,  and  engineering  analysis  programs. 
Computer  programs  may  be  general  purpose  in  nature  or  be  designed  to 
satisfy  the  requirements  of  a  specialized  process  or  a  particular 
user. 

Computer  Resources  --  The  totality  of  computer  equipment,  computer  programs, 
computer  data,  associated  computer  documentation,  contractual  services, 
personnel,  and  computer  supplies. 

Computer  Software  —  A  combination  of  associated  computer  programs,  documen¬ 
tation,  and  computer  data  required  to  conmand  the  computer  equipment 
to  perform  computational  or  control  functions. 

Computer  Software  Documentation  —  Technical  data,  including  computer  list¬ 
ings  and  printouts  in  human-readable  form,  which  specifies  the  design 
or  details  of  computer  software,  explains  the  capabilities  of  the 
computer  software  or  provides  operating  instructions  for  using  the 
computer  software  to  obtain  desired  results  from  computer  equipment. 

For  the  purpose  of  documentation,  the  term  software  includes  all  infor¬ 
mation,  data,  analysis,  algorithms,  flowcharts,  etc.,  which  have  been 
generated,  acquired,  or  applied  in  developing  computer  programs  for  the 
system  and  system  support  equipment.  This  analysis,  program  coding, 
flowcharts,  algorithms,  interface  definitions,  technical  manuals,  source 
and  object  decks  and  listings,  test  plans/procedures/reports,  and 
support  programs  and  their  documentation. 

Computer  System  —  An  interacting  assembly  consisting  of  computer  equipment, 
computer  programs,  and  computer  data. 

Computer  System  Documentation  —  Information  that  describes  the  technical 
details  of  the  computer  system  over  its  life  cycle.  Documentation 
includes,  but  is  not  limited  to,  equipment  design  specifications, 
engineering  drawings,  operator's  manuals,  technical  orders,  computer 
software  documentation,  systems  specifications,  run  diagrams,  and 
interface  specifications. 

Configuration  —  The  functional  and  physical  characteristics  of  materiel, 
as  described  in  technical  documents  and  achieved  in  a  product. 
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Configuration  (Change)  Control  Board  (CCB)  —  A  board  composed  of  represent¬ 
atives  from  program/project  functional  areas  such  as  engineering,  config¬ 
uration  management,  procurement,  production,  test  and  logistic  support, 
training  activities  and  using/supporting  organizations.  This  board  ap¬ 
proves  or  disapproves  proposed  change  requests  with  each  member  recording 
his  organization's  official  position  as  regards  the  CCB  Chairman's  deci¬ 
sion.  The  prog ram/ project  manager  is  normally  the  board  chairman  and  he 
makes  the  final  decision  on  all  changes  unless  otherwise  directed  by 
command  policy.  The  board  issues  a  directive  to  implement  its  decision. 

Configuration  Identification  --  Documents  which  identify  and  define  the 
configuration  baseline  characteristics  of  an  item. 

Configuration  Item  (Cl)  —  An  aggregation  of  hardware/software,  or  any  of  its 
discrete  portions,  which  satisfies  an  end-use  function  and  is  designated 
by  the  Government  for  configuration  management.  CIs  may  vary  widely  in 
complexity,  size,  and  type,  from  an  aircraft,  electronic,  or  ship  system 
to  a  test  meter  or  round  of  ammunition.  During  development  and  initial 
production,  CIs  are  only  those  specification  items  that  are  referenced 
directly  in  the  contract  (or  an  equivalent  in-house  agreement).  During 
the  operation  and  maintenance  period,  any  repairable  item  designated  for 
separate  procurement  is  a  Cl  (DoD  Directive  5010.19). 

Configuration  Management  (CM)  —  A  discipline  applying  technical  and  admini¬ 
strative  direction  and  surveillance  to  (1)  identify  and  document  the 
functional  and  physical  characteristics  of  a  configuration  item,  (2) 
control  changes  to  those  characteristics, ‘and  (3)  record  and  report 
change  processing  and  implementation  status.  It  includes  configuration 
identification,  control,  status  accounting  and  audits. 

Design  —  The  process  by  which  functional  requirements  are  translated  into 
product  or  procedure  specifications  to  be  used  in  the  development  of  a 
system  or  subsystem. 

Embedded  Computer  Resources  (ECR)  --  Computer  resources  dedicated  to  and 
essential  to  the  performance  of  the  Army  BAS  mission  when  physically 
incorporated  in  the  system  or  when  separated  selection,  acquisition, 
and/or  management  of  the  computer  resources  would  not  be  feasible,  or 
when  the  computer  resources  are  integral  to  the  BAS  from  a  design,  pro¬ 
curement,  and  operations  viewpoint. 

Emulation  --  The  imitation  of  an  entire  system  with  another  system  so  that 
the  imitating  system  is  capable  of  accepting  the  same  data,  executing 
the  same  programs,  and  producing  the  same  results  as  the  original  system. 

Engineer  —  This  functional  area  which  is  included  in  the  Maneuver  BFA, 

brings  to  the  battlefield  a  terrain-oriented  system  designed  to  enhance 
the  capabilities  of  U.S.  weapons  systems  while  decreasing  the  effective¬ 
ness  of  the  enemy  weapons. 
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Engineering  Change  Proposal  (ECP)  —  A  term  that  includes  both  a  proposed 

engineering  change  and  the  documentation  by  which  the  change  is  described 
and  suggested. 

Fire  Support  --  This  BFA  is  the  major  contributor  of  fire  support  for 
maneuver  forces. 

Fielded  Software  —  The  software  that  is  deployed  in  and  with  the  tactical 
equipments. 

Functional  Proponent  —  The  Army  Staff  agency  responsible  for  the  subject 
area  in  which  automation  is  used  or  is  to  be  used,  including  automation 
in  support  of  the  function  performed. 

Independent  Testing  --  Testing  not  of,  by,  or  with  the  Combat  or  Materiel 
Developer's  design  and  implementation  team. 

Intelligence  and  Electronic  Warfare  —  This  BFA  assists  the  commander  and 
his  staff  in  knowing  and  understanding  the  enemy  and  in  seeing  the 
battlefield  through  surveillance  and  target  acquisition.  In  its 
electronic  capability  this  BFA  attacks  or  defends  systems  that  employ 
electromagnetic  energy,  including  command  and  control,  weapon  and 
acquisition  systems. 

Interoperability  --  The  capability  of  a  system  to  receive  and  process 

intelligible  information  between  or  among  other  systems  regardless  of 
whether  the  systems  perform  the  same  battlefield  function. 

Logistics  —  This  functional  area  which  is  included  in  the  Combat  Service 
Support  BFA,  supports  decision  making  of  each  tactical  echelon  by  pro¬ 
viding  decisive  and  timely  logistic  and/or  technical  expertise  as  far 
forward  as  possible  to  give  the  tactical  command  a  full  complement  of 
operating  equipment  and  weapons. 

Maintenance  —  Routine,  recurring  work,  associated  with  correcting  faults, 
performed  to  keep  a  system  at  of  to  achieve  its  intended  capability 
or  designed  performance. 

Major  Items/Systems/Programs  (AR  1000-1)  --  All  acquisition  programs  whose 
estimated  costs  exceed  $75  million  in  RDTE  or  $300  million  in  procure¬ 
ment  appropriations,  unless  exception  is  approved  by  VSCA  or  the  program 
is  exempted  by  SECDEF. 
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Major  System  --  Selected  materiel  systems  acquisition  programs  designated  by 
HQOA  as  Army  major  systems  to  be  subjected  to  management  reviews  by  the 
ASARC.  This  designation  is  normally  a  part  of  the  ROC  approval  process 
accomplished  as  a  prelude  to  entry  into  full-scale  engineering  develop¬ 
ment.  In  addition,  those  Army  systems  designated  by  the  Secretary  of 
Defense  for  DSARC  review  are  automatically  identified  as  Army  major 
systems. 

Maneuver  --  This  BFA,  through  its  inherent  subsystems  of  direct  fire  and 
integration,  provides  the  timely  means  to  generate  and  apply  decisive 
combat  power  on  the  modern  battlefield.  Also  included  in  this  BFA  are 
the  functional  areas  of  Air/Ground,  Engineer  and  that  portion  of  Command 
and  Control  in  the  area  of  planning. 

Materiel  Developer  --  The  command  or  agency  responsible  for  research, 

development,  and  production  validation  of  an  item  (including  the  system 
for  its  logistic  support)  which  responds  to  DA  objectives  and  requirements. 

Post-Deployment  Software  Support  (PDSS)  --  That  part  of  over-all  system 
support  necessary  to  sustain,  modify,  and  improve  a  deployed  systems 
computer  software  (instructions,  programs,  data,  etc.)  as  defined  by 
the  user  or  his  representative. 

Post-Deployment  Software  Support  (PDSS)  Center  —  A  facility,  managed  by  the 
Materiel /System  Developer,  with  necessary  equipment  and  personnel  to 
provide  PDSS  to  designated  BAS. 

Product  Improvement  Proposal  (PIP)  —  A  reconfiguration  of  an  end  item  of 
Army  or  multi-Service  materiel  type-classified  standard  that  is  funded, 
managed,  and  completed  as  a  single  project.  The  term  "PIP"  is  applied 
to  the  project  from  its  start  as  a  proposal  through  its  completion. 

Proponent  Agency  (PA)  —  The  element  assigned  responsibility  by  the  functional 
proponent  for  the  functional  design,  development,  implementation,  and 
maintenance  of  an  automated  system. 

Requirements  Document  —  Any  of  two  types  of  documents  that  formally  state 
the  user's  needs. 

a.  Acquisition  documents  requiring  preparation  of  and  support  by  a 
BOIP,  i.e.,  Required  Operational  Capabilities  (ROC),  Letter  Require¬ 
ments  (LR),  Training  Device  Requirements  (TDR),  Training  Device  Letter 
Requirements  (TDLR),  and  Letters  of  Agreement  (LOA). 

b.  Tables  of  Organization  and  Equipment  (TOE).  A  table  which  pre¬ 
scribes  the  normal  mission,  organizational  structure,  and  personnel  and 
equipment  requirements  for  a  military  unit  and  is  the  basis  for  an 
authorization  document. 
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Simulation  --  The  representation  of  certain  features  of  the  behavior  of  a 
physical  or  abstract  system  by  the  behavior  of  another  system,  e.g., 
the  representation  of  physical  phenomena  by  means  of  operations  per¬ 
formed  by  a  computer  or  the  representation  of  operations  of  a  computer 
by  those  of  another  computer. 

Software  Quality  --  The  composite  of  materiel  attributes  including  per¬ 
formance  which  describes  the  degree  of  excellence  of  the  computer 
software;  features  and  characteristics  of  a  product  or  service  to 
satisfy  a  given  need. 

Support  --  All  the  actions  and  procedures  necessary  to  maintain  and  sustain  a 
system  in  an  operational  condition  acceptable  to  the  Combat  Developer. 

Support  Software  --  The  software  used  to  develop  and  maintain  the  fielded 
software. 

Support  System  --  Computer  resources  used  to  develop  or  support  battlefield 
automated  systems. 

System  —  An  integrated  relationship  of  components,  aligned  to  establish 
proper  functional  continuity  towards  the  successful  performance  of  a 
defined  (required)  task  or  tasks. 

System  Baseline  —  A  known  entity  used  as  a  control  to  determine  system 
performance. 

Tactical  --  Deployed  at  or  below  corps  echelons. 

Tactical  Data  Systems  —  An  automated  data  processing  system  which  supports 
the  decision  making  process  for  combat  and  combat  support  functions,  as 
opposed  to  direct  control  of  weaponry,  with  respect  to  battlefield 
tactics  and  or  employment  of  combat  weapons  systems. 

Training  Developer  —  The  training  developer  function  i^  an  activity  per¬ 
formed  by  a  variety  of  personnel  in  the  training  development  process. 

The  system  approach  to  training  model  provides  a  broad  framework  for 
the  development  of  efficient  and  effective  training  through  the  perfor¬ 
mance  of  diverse  but  complimentary  systems  functions.  These  functions 
encompass  the  analysis,  design,  development,  implementation  and 
evaluation  of  the  training  system. 

User  —  The  command  or  agency  ultimately  intended  to  employ  an  item  of  equip¬ 
ment  and  so  designated  by  DCSOPS  (AR  1000-1)  when  approving  the  require¬ 
ment  document.  The  user  or  user  representative  provides  guidance  to  the 
developer  throughout  the  materiel  acquisition  process  on  matters  pertain 
ing  to  the  expected  operational  employment  of  the  item.  Unless  another 
command  is  so  designated,  TRADOC  will  act  as  the  user  representative 
and  will  carry  out  the  "user"  functions. 
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Utility  —  Computer  software  module  that  performs  a  single,  identifiable 
operation  in  the  execution  of  a  battlefield  function.  Examples  are 
data  collection,  data  dissemination,  data  sort,  equipment  control, 
scheduling,  and  interface  protocol  management. 

Validation  —  All  evaluation,  integration  and  test  activities  carried  out 
at  the  system  level  to  ensure  that  the  finally  developed  system 
satisfies  the  requirements  of  the  system  specification. 

Verification  —  The  iterative  process  of  determining  whether  the  product  of 
selected  steps  of  the  CPCI  development  process  fulfills  the  requirements 
levied  by  the  previous  step.  The  process  is  to  ensure  that  CPCI  develop¬ 
ment  specifications  reflect  the  requirements  allocated  from  the  system 
specification. 
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APPENDIX  C 

BATTLEFIELD  AUTOMATED  SYSTEMS  (BAS) 


C-1.  CONTENT  OF  APPENDIX.  This  appendix  contains  the  Battlefield  Automated 
Systems  (BAS)  addressed  during  this  Post-Deployment  Software  Support  (PDSS) 
Study  organized  by  their  Battlefield  Functional  Area  (BFA).  Consistent  with 
current  doctrinal  literature,  there  are  now  considered  to  be  five  BFA's  and 
two  functional  areas  instead  of  the  11  former  BFA's  that  were  recognized. 

Figure  C-l  clarifies  this  new  classification  in  relationship  to  the  11  former 
BFA's.  Figures  C-2  through  C-8  list  the  systems  according  to  this  new  class¬ 
ification  and  identify  the  system  proponent,  development  command,  readiness 
command,  and  projected  PDSS  center. 

C-2.  SYSTEM  CATEGORIES.  The  focus  of  this  study  has  been  on  System  Categories 
1,  2A  and  2B  as  defined  in  the  PDSS  Concept  Plan  for  BAS,  May  1980,  since 
those  are  the  systems  with  which  TRADOC  is  principally  concerned  with  respect 
to  PDSS: 

a.  Category  1  systems  are  defined  as  large  (over  100K  lines  of  code) 
evolutionary  systems  and  include  SIGMA,  ASAS,  TACFIRE,  AN/TSQ-73,  PATRIOT, 

CSS  Control  System,  AN/MSM-105(V) ,  and  PLRS/JTIDS  Hybrid. 

b.  Category  2A  systems  are  defined  as  small  (less  than  TOOK  lines  of 
code)  evolutionary  systems,  e.g.,  DIVAD  GUN,  Battery  Computer  System  (BCS), 
and  SHORAD  C2. 

c.  Category  2B  systems  include  large  stable  systems,  e.g.,  PLRS,  SOTAS, 
and  ADDS. 

d.  Category  3  systems  are  small  stable  systems  in  which  the  software 
is  normally  transparent  to  the  user  and  is  not  expected  to  change  greatly 
once  the  system  is  fielded. 

C-3.  CATEGORIZATION  SOURCE.  The  above  system  categorization,  used  during 
this  study  was  accomplished  during  a  previous  DARCOM-initiated  study,  Post- 
Deployment  Software  Support  (PDSS)  Concept  Plan  for  Battlefield  Automated 
Systems,  May  1980. 
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BATTLEFIELD  FUNCTIONAL  AREAS  (BFA) 

FORMER  CLASSIFICATION 

1.  FORCE  LEVEL  CONTROL  BFA 

FORCE  LEVEL  CONTROL  FUNCTIONAL  AREA 
(THAT  PORTION  WHICH  AFFECTS  THE 
COMMANDER  AND  HIS  STAFF  IS  NOW  CON¬ 
SIDERED  TO  BE  IN  THE  FORCE  LEVEL 
CONTROL  AREA  AND  TO  INTERACT  WITH 

THE  FIVE  BFA'S  LISTED  BELOW.) 

2.  MANEUVER  BFA 

3.  AIR  GROUND  BFA 

4.  ENGINEER  BFA 

1.  MANEUVER  BFA  (ALSO  INCLUDES  THAT 
PORTION  OF  COMMAND  AND  CONTROL 

IN  THE  AREA  OF  PLANNING.) 

5.  AIR  DEFENSE  BFA 

2.  AIR  DEFENSE  BFA 

6.  FIRE  SUPPORT  BFA 

3.  FIRE  SUPPORT  BFA 

7.  LOGISTICS  BFA 

8.  ADMINISTRATION  BFA 

4.  COMBAT  SERVICE  SUPPORT  BFA 

9.  INTELLIGENCE  BFA 

10.  ELECTRONIC  WARFARE  BFA 

5.  INTELLIGENCE  AND  ELECTRONIC 
WARFARE  BFA 

11.  COMMUNICATIONS  BFA 

COMMUNICATIONS  FUNCTIONAL  AREA  (IS 

NOW  CONSIDERED  TO  BE  A  SUPPORT 
FUNCTIONAL  AREA  WHICH  SUPPORTS  AND 
INTERACTS  WITH  THE  FIVE  BFA'S 

LISTED  ABOVE.) 

Figure  C-l.  Classification  of  the  current  functional  areas  in 
relationship  to  the  11  former  BFA's 


Figure  C-2.  Force  Level  Control  System 
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Figure  C-3  (concluded) 
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Figure  C-5.  Fire  Support  BFA  Systems  (continued  on  next  page) 
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*Not  categorized  but  treated  as  Category  2  for  PDSS  planning. 

Figure  C-6.  Combat  Service  Support  BFA  Systems  (continued  on  next  page) 


Not  categorized  but  treated  as  Category  2  for  PDSS  planning. 

Figure  C-6.  (continued) 
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gure  0-8.  Communications  Systems  (continued  on  next  page) 


CATE-  DEVELOPMENT  READINESS  PDSS  CENTER 

SYSTEM  GORY  PROPONENT  COMMAND  COMMAND  LOCATION  |  MANAGED  BY 

PLRS 

POSITION  LOCATION  REPORTING  2B  USASC  CORADCOM  (FT.  CERCOM  FT.  MONMOUTI  CORADCOM 
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Also  addressed  under  Command  and  Control  Functional  Area. 


CATE-  DEVELOPMENT  READINESS  PDSS  CENTER 

SVSTEM  GORY  PROPONENT  COMMAND  COMMAND  LOCATION  MANAGED  BY 

MSE 

MOBILE  SUBSCRIBER  3  DCA  CORADCOM  (FT.  CERCOM  FT.  MONMOUTH  CORADCOM 

EQUIPMENT  MONMOUTH) 


Not  categorized  but  treated  as  Category  2  for  PDSS  planning. 

Figure  C-8.  (continued) 
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APPENDIX  D 

SUMMARY  OF  QUESTIONNAIRE  RESPONSES 


D-l.  GENERAL. 

a.  This  appendix  contains  a  summary  of  the  responses  received  to 
date  to  the  questionnaire  that  was  prepared  and  administered  during  Phase 

I  of  the  study.  These  questionnaires  were  distributed  to  selected  personnel 
at  TRADOC  Doctrinal  Centers  during  visits  by  Study  Team  members. 

b.  The  purpose  of  the  questionnaire  was  to  obtain  more  detailed  data 
pertaining  to  individual  Category  1  and  2  and  CSC-developed  systems  ad¬ 
dressed  during  the  study,  than  could  conveniently  be  obtained  during  inter¬ 
views  and  discussions.  The  questionnaire  included  an  explanation  of  its 
purpose,  administrative  instructions,  and  32  questions.  The  questions 
focused  principally  on  actions  related  to  the  Combat  Developer's  role  in 
post-deployment  software  support. 

c.  At  the  time  this  report  was  prepared,  39  completed  questionnaires 
had  been  returned  to  the  Study  Team.  These  address  30  of  the  41  systems  on 
which  a  questionnaire  was  requested.  Thirteen  of  these  30  systems  are  at  or 
beyond  Initial  Operational  Capability  (IOC).  The  other  17  are  in  various 
phases  of  development.  All  questionnaire  respondents  were  either  members  of 
a  TSM  Office,  a  US  Army  Test  Board,  or  a  Combat  Development  staff  element 
with  assigned  responsibilities  associated  with  system  development  and  life 
cycle  management. 

d.  The  questionnaires  received  have  been  analyzed  for  information 
that  would  contribute  to  the  development  of  insights  into  the  role  of  the 
Combat  Developer  in  planning  for  and  providing  PDSS  for  BAS.  Results 
derived  are  summarized  below. 

D-2.  QUESTIONNAIRE  RESPONSES. 

a.  The  completed  questionnaires  indicate  that  virtually  all  of  the 
respondents  recognize  that  they  have  certain  responsibilities  associated  with 
PDSS.  Responsibilities  described  in  the  responses  generally  center  on  three 
areas,  (1)  acting  as  User  representative,  (2)  performing  system  testing,  and 
(3)  defining  functional  requirements  of  the  system  with  which  they  are  con¬ 
cerned.  The  percent  of  their  duty  time  that  respondents  indicate  is  devoted 
to  PDSS  varies  from  zero  to  100  percent  with  most  indicating  about  one  to 
three  percent. 

b.  Most  responses  state  that  system  software  requirements  were  developed 
by  the  Combat  Developer  and  included  in  the  system  requirements  or  specific- 
tion  document.  However,  several  responses  indicate  that  these  requirements 
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were  not  developed  to  the  degree  of  detail  desired  by  either  the  Combat 
Developer  or  Materiel  Developer.  Results  of  other  Phase  I  research 
conducted  by  the  Study  Team  supports  the  view  expressed  in  these  responses. 

c.  Eighteen  of  the  39  responses  indicate  that  fairly  specific  procedures 
have  been  developed  for  addressing  User-identified  system  software  problems. 
Considering  that  17  of  the  30  systems  addressed  by  the  completed  questionnaires 
have  not  reached  IOC,  this  distribution  of  responses  might  be  expected. 

However,  of  the  11  affirmative  responses,  only  four  indicate  that  the  Combat 
Developer  has  a  prominent  role  in  the  process  of  addressing  User-reported 
software  problems.  These  problems  appear  to  be  handled  primarily  between 

the  User  and  Materiel  Developer  or  Contractor. 

d.  Only  four  responses  indicate  that  software  support  requirements  and 
response  times  in  a  crisis/combat  environment  have  been  addressed  specifically. 
Even  though  some  of  the  systems  addressed  by  the  questionnaires  are  in  early 
development,  this  low  number  of  affirmative  responses  suggests  that  further 
attention  needs  to  be  focused  on  crisis/wartime  software  support  requirements 
and  procedures. 

e.  Only  three  responses  indicate  knowledge  of  the  preparation  of  a 
Computer  Resources  Management  Plan  (CRMP)  or  Combat  Developer  participation 
on  a  Computer  Resources  Working  Group  (CRWG)  for  the  system  being  addressed. 
This  reflects  limited  participation  by  the  Combat  Developer  in  PDSS  planning 
that  should  be  initiated  early  in  the  system  development  cycle. 

f.  With  respect  to  system  configuration  management,  15  responses  state 
that  a  system  Configuration  Control  Board  (CCB)  has  been  formed  for  the 
system  addressed.  These  15  responses  plus  five  others  identified  the  Combat 
Development  element  responsible  for  participation  in  system  configuration 
control  functions.  Other  responses  indicate  no  knowledge  of  the  existence 

of  a  CCB  for  their  system. 

D-3.  ADDITIONAL  RESPONSES.  Additional  responses  to  the  questionnaire  are 
anticipated.  As  these  are  received,  they  will  be  analyzed  and  results 
incorporated  into  the  data  base  to  support  accomplishment  of  Phase  II. 


